from Hacker News

Scalable OLTP in the Cloud: What's the Big Deal?

by SchwKatze on 1/27/25, 1:24 AM with 49 comments

• by taeric on 1/30/25, 5:18 PM

  Fun read. I am a bit curious on not mentioning OLAP, at all?

  From my experience, the vast majority of complications in systems is people not realizing they are asking an OLAP question while wanting parts of OLTP semantics.

  I'm also curious how much of this extra complication comes from having a central database that tries to be a source of truth for everything? As an easy example, inventory systems that try and have a cloud source of truth have obvious problems when on the ground inventory issues crop up. That is, a lot of the complication is between the distributed nature of the application and database, sure. But, another large source is the non-distributed abstraction that a central database can represent not centralized activity.

• by whartung on 1/30/25, 6:14 PM

  Maybe someone can answer how this is done.

  Simply, the mad crushing dash to get the last bit of committed inventory.

  Ticketmaster has 50,000 General Admission Taylor Swift tickets and 1M fans eager to hoover them up.

  This is a crushing load on a shared resource.

  I don't know if there's any reasonable outcome from this besides the data center not catching on fire.

• by danpalmer on 1/30/25, 11:10 PM

  Surprising that neither this post nor the linked paper that it's about talk about Spanner, and instead only look at Oracle/SQL Server/Postgres. From what I understand, Spanner really does scale up OLTP to global level, where those alternatives struggle beyond regional level.

• by theLiminator on 1/31/25, 12:54 AM

  I'm really curious about the capabilities of https://cedardb.com/ they claim that they can make a single DB that does both OLTP and OLAP. It's basically the production version of umbra.

• by vsipuli on 1/31/25, 3:47 AM

  How does this compare to Amazon Aurora DSQL (https://aws.amazon.com/rds/aurora/dsql/)?

• by solatic on 1/31/25, 1:12 PM

  Database design fundamentally trades off the speed of acknowledging writes with durability/availability (these are the same thing at scale) guarantees. If you need to guarantee that a change has been replicated globally then you cannot acknowledge the write as quickly as if you have a single control server with no need for persistence.

  "Scalable"? Needs more context please. Scalable how? And what are you willing to compromise on for that scale?

• by honestSysAdmin on 1/30/25, 5:50 PM

  I could be wrong here, I'm not an expert with databases, but I believe -- this is a belief, please help me disconfirm it if you think it is wrong -- that CitusDB's approach that shards Postgres across redundant mirrors, should successfully scale horizontally for OLTP without sacrificing consistency.

• by teekert on 1/31/25, 10:14 AM

  Ah yes, not the One Laptop Child Per, as I'm typing it, I see my error. This is some DeepSeek level reasoning right here.