Did you know that Postgres has a max table size of 32TB? Its really really fun to find that out the Wednesday evening before Thanksgiving.
Make sure to prune old data from your tables. This one got to this limit because it eventually got too large that queries to delete old data would time out... so it just kept growing.
For 90%+ of our customers (small-to-mid sized US financial institutions), production is the only environment available to work with.
For the other 10%, we take them aside and politely explain that they almost certainly have an unusable staging environment per the scope of our B2B project.
Testing in production is a wonderful path if you are comfortable talking to business people and making lots of compromises.
This sounds very exciting, but I would have greatly appreciated some actual technical details. From this statement
> Sharded tables – These tables are distributed across multiple shards. Data is split among the shards based on the values of designated columns in the table, called shard keys.
It sounds like this is very much managed CitusDB on top of Aurora, but without any details about the implementation its impossible to know if its just repackaged Citus, or some new novel technology built specifically for Aurora.
Aurora Limitless Database is based on our own investments in database-optimized virtualization (Caspian), in scale-out log-first database storage (Grover)[2], and in a custom approach to cross-shard transactions that makes use of the high-quality hardware clocks available in EC2[1]. We'll be talking more about the internals over the coming months.
I'm glad someone from AWS is here! Some general info on the sharding approach would be interesting, e.g. whether secondary indices on sharded tables are scatter-gather, or separately sharded on the index columns, or you configure it per index, or what.
From what I hear from folks using things like Vitess, if you're used to a monolithic SQL database there's often some things to learn to mentally model your query cost well after you move to a sharded world, and understanding more up front can save heartburn later. Writing up those details well is a good thing that AWS could do.
I appreciate the context, but this just adds so many more questions. How are you integrating hardware clocks into the Postgres transaction model? Is this just postgres wire compatible like Cockroach or Yugabyte, or have you modified Postgres MVCC implementation to not use the standard TID. Does this support all of postgres at the Transaction coordinator ?
Super exciting announcement, and I am really looking forwards to learning more!
but Spanner isn't Postgres compatible, they have their own transaction processing layer that is built for TrueTime. If this is using the Postgres frontend how are they incorporating TrueTime into the normal Postgres MVCC model that uses the monotonic xid.
edit: More details make it seem like this _isn't_ Postgres on the frontend, its just mostly postgres compatible, which would explain how they got away from the xid based MVCC. So it seems like this is an entirely new distributed database, rather then a modification to existing postgres.
I think they are internally using postgres only. aurora uses a custom storage process on host which internally supports the custom storage engine (s3)
given the mentions of "log as a database", I believe that depending on the transaction the storage responds differently. like how mysql mvcc uses undolog to essentially rollback database internally so that transaction sees data consistency. they could be doing something similar i.e regardless of whatever postgres uses, if they can get a reference of transaction and its start time then they can use the custom storage engine to rollback the log and respond in that way
remember it is aws, "leverage" is built into their DNA, I don't believe that they would go on the route of building a totally new SQL database like google did
This does look exactly like CitusDB even in the naming of some things (reference / distributed tables) and how they describe it being added to an existing cluster as extra nodes with an extra manager node that will redirect requests!
I want to better understand the reasoning behind the "scale to zero" point that many people mention.
only case I could think of is that businesses that want "scale to zero" have very low total expenditure on the database. is this the case for you as well?
because serverless without going to zero still solves a major problem for a lot of companies with some decent scale, where there is some decent traffic and its too hard to implement database autoscaling and most businesses have unequal traffic (daytime and nighttime etc,...)
Yeah, can’t really see any overlap in the camps of folk who want “scale to zero” and those who want the “automatically horizontally sharded ginormous transaction scale” that this post is about.
Why not have both? That's exactly what DynamoDB offers, and people want the SQL equivalent promise of "it'll keep up no matter what scale you're at".
The point is: You don't want to need to switch technology at a later stage, you'd like to build with the right technology from the get-go.
I almost always go for DynamoDB first, since for small projects it's essentially free, and for huge projects I do not have to worry about the ops overhead that follows normal SQL databases.
A lot of people also have traffic patterns that go:
- Very high volume during the day
- Almost no or little volume during the night when your users are sleeping
Aurora Serverless v2 gets us closer to this for SQL, but does not scale to 0 so it's not too nice for the initial phases of projects.
What are you referring to? I didn’t see anything described that’s exclusive to Spanner. CockroachDB is a Postgres-compatible-ish distributed DB that does multi shard transactions. YugabyteDB is another that comes to mind. CitusDB is a Postgres extension that manages multi shard tables. Or are you referring to automatic scale-out?
Not sure i would say Spanner is the only database that can do this... first of all, this new thing from AWS can't do what spanner can do and second, there are few that can deliver distributed transactions in addition to Spanner, such as CockroachDB (ex-emplyer), Yagbyte and TiDB.
> Join the preview of Amazon Aurora Limitless Database
would be the non-editorialized submission, and would have advised potential readers that one cannot currently play with it without a ton of hoopjumpery
one will also want to watch out for this, buried 7 paragraphs in:
> The preview runs in a new Aurora PostgreSQL cluster with version 15 in the AWS US East (Ohio), US East (N. Virginia), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland) Regions.
> But AWS isn’t gouging customers, otherwise you’d expect to see some things that I don’t find evident here; for example, data egress charges are the same price in us-west-1 as in other U.S. regions.
As if data egress charges aren't gouging customers everywhere!
We are using the ~equivalent SQL Server architecture in Azure right now (Hyperscale tier) and really enjoy the experience. Not having to worry about specific machines and being able to treat it the same way as an express instance (from an app perspective) are extremely compelling selling points.
The only downside I saw in the Microsoft offering was the fact that there was a throttle for transaction log writes (100 megabytes/s) which is required to maintain resilience across the cluster. You don't want your replicas to wind up 3 weeks behind, etc. My hope is this limit will only increase with time, but even so it is quite workable (for us) today.
I may spin up an instance of Aurora (when available) to take a look at how it behaves around our worst-case serialized txn paths. Our use of SQL Server is very "light" in terms of its weird claws/hooks, so we could pretty easily shift to another RDBMS vendor in the future, assuming we can sell our clients on the 3rd party mix.
That is quite the ambitious name, obviously it can't really be "limitless" even if that limit is just whatever spare resources AWS has to run your database.
But they must be confident that that whatever the real limit is, is just not realistic for any use case.
Isn't it more or less automated? Create an Aurora replica cluster from your normal RDS database, switch your application over and then delete the old RDS instance.
what if your postgres instance has replicas?
They support blue/green for RDS postgres, but not for RDS/Aurora.
It's slated for later next year is what I heard.
Literally just today I was looking into a new project that requires postgres, and read on the aurora doc that this exists. Didn't look further into it considering the project is new and no migration is involved, but if you need this, worth searching.
> a new capability supporting automated horizontal scaling to process millions of write transactions per second and manage petabytes of data in a single Aurora database.
Limitless horizontal scaling is really cool and all, but does anyone not running a Fortune-500 Tech company actually need this kind of firepower?
At Notion we run ~100 Postgres instances and we’re pretty far off from being Fortune 500, although we have many Fortune 500 clients. We could have used this Aurora thing instead of doing sharding in the application ourselves: https://www.notion.so/blog/sharding-postgres-at-notion
Separation of compute and storage, and storage having tables being sharded is now in many modern databases (cockroachdb, clickhouse and singlestore come to mind).
This being part of native aws fully postgres compatible is exciting though.
I wish AWS brings columnstore or custom storage engine features.
But I can see why AWS wouldn’t want to bring columnstore tables - it would directly compete with redshift.
AWS does a lot of enterprise business but I’d also think about it as setting the upper bounds: you probably don’t need millions of transactions per second but if you’re a startup needing, say, thousands it’s nice knowing that you don’t need to fundamentally rearchitect for a while even if you become popular. The pain of hitting the limits of a single database write node can be high because you need to make substantial changes to what is by definition a busy system, but you have an incentive not to make the big changes until you need them since they make everything else more work. This gives you the option of effectively never needing to do that, which is going to be popular with anyone anticipating lots of growth if it delivers as advertised.
