7 ms·
Amazon Aurora Limitless Database
- deleted 3y ago[deleted]
- Agent766 3y agoI can't wait until people find its limits!
- amtamt 3y agoReminds of unbreakable linux.
- nusmella 3y agoI can't wait until people find its limits... in production!
- rilindo 3y agoProduction is the best testing environment after all.
- jimt1234 3y agoI don't always test my code. But when I do, I test it in production. -The Most Interesting Man in the World
- bob1029 3y agoFor 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.
- recursive 3y agoEveryone has a testing environment. Some people even have separate production environments.
- kiernanmcgowan 3y agoDid 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. https://www.postgresql.org/docs/current/limits.html https://www.postgresql.org/docs/current/limits.html
- teaearlgraycold 3y agoI just put a maximum Postgres table size I’m willing to manage in my employment contract. By the time we’re measuring in Terabytes I’m out of there.
- drewda 3y agoFor an interesting presentation on Postgres at different orders of magnitude, all the way up to petabytes, see https://thebuild.com/presentations/2019-fosdem-broken.pdf https://thebuild.com/presentations/2019-fosdem-broken.pdf
- victorbjorklund 3y agoWow. That is still pretty large for one table.
- alex_127 3y agoit is partitioned underneath with limit of 32TB for single partition. (hello ctid). there could be many of them.
- joelrwilliams1 3y agoI'm going to guess that Amazon.com will be one of the first to find all of the limits.
- Dowwie 3y agoAWS team needs to automate migrations from RDS to Aurora
- figmert 3y agoLiterally 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.
- lysecret 3y agoI did it it was the craziest process but it worked eventually even though that was quite a while ago.
- aeyes 3y agoIsn'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.
- sharadov 3y agowhat 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.
- mdaniel 3y ago> 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.
- Aeolun 3y agoSo basically 70% of AWS users can use it if they get accepted to the preview? Those regions seem chosen because they’re the biggest ones.
- bdcravens 3y agoKeep in mind that the California region has been devalued for a while. AWS would turn it off if they could. https://www.lastweekinaws.com/blog/us-west-1-the-flagship-aws-region-that-isnt/ https://www.lastweekinaws.com/blog/us-west-1-the-flagship-aw...
- immibis 3y ago> 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!
- mperham 3y agoThank you for the word "hoopjumpery".
- nerdjon 3y agoThat 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.
- acdha 3y agoI believe it means “the bill will have you on the phone with your TAM discussing alternatives before you exceed what we can host”.
- dkhenry 3y agoThis 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.
- bdcravens 3y agoLikely it'll be talked about in-depth this week at Reinvent. This intro article is par for AWS "product announcements".
- mjb 3y agoAurora 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. [1] https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-time-sync-service-microsecond-accurate-time/ https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-ti... [2] https://assets.amazon.science/dc/2b/4ef2b89649f9a393d37d3e042f4e/amazon-aurora-design-considerations-for-high-throughput-cloud-native-relational-databases.pdf https://assets.amazon.science/dc/2b/4ef2b89649f9a393d37d3e04...
- tristor 3y ago> makes use of the high-quality hardware clocks available in EC2 So are you using vector clocks in the backend to handle transaction ordering and maintain consensus?
- alex_127 3y agovector (or matrix) clocks are awfully slow in real life. have shipped product with this, will not recommend for future.
- penguinpower 3y ago> 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?
- Aeolun 3y agoThe people running a fortune 500 company are the majority of AWS income? I’d say it’s very relevant to them.
- bdcravens 3y agoMost AWS products outside of the core group (EC2, S3, RDS, Lambda, etc) are for the enterprise or venture-backed startups.
- jitl 3y agoAt 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 https://www.notion.so/blog/sharding-postgres-at-notion
- nojvek 3y agoSeparation 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.
- acdha 3y agoAWS 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.
- lysecret 3y agoI used aurora for a while and liked it quite a bit (especially compared to Alloydb which was absolutely horrible).
- bdcravens 3y agoAh yes, Reinvent season, when all of the AWS announcements make the front page of HN but most won't be generally available for 6-12 months.
- scarface_74 3y agoIt’s just the opposite of what happens with Google. They announce a product that is available today. But won’t be available in 6-12 months.
- sidcool 3y agoThis is some seriously impressive engineering. Spanner is the only DB that can achieve this.
- jitl 3y agoWhat 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?
- jaymce 3y agoNot 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.
- icpmacdo 3y agoSharing here a wonderful MIT lecture on the architecture of Aurora I recently watched https://www.youtube.com/watch?v=jJSh54J1s5o https://www.youtube.com/watch?v=jJSh54J1s5o
- adamgordonbell 3y agoWhat type of consistency guarantees are involved? Are we giving away something to get multiple writers to same table? Or does the routing to the correct shard somehow solve for that?
- smlacy 3y agoIt's web scale!
- ldjkfkdsjnv 3y agoThings I want in a serverless database: 1. Scales to zero, no cost when not using 2. Allows for SQL over API like aurora v1. This point is important, it allows for faster access from other serverless technologies, i.e. lambda
- eightnoteight 3y agoI 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,...)
- dalyons 3y agoYeah, 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.
- Tehnix 3y agoWhy 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.
- bob1029 3y agoThese architectures are super interesting to me. 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.
- didibus 3y agoIs this available for Aurora Serverless V2 as well?
- syspec 3y agoThis is a great blog post, I feel that this level of database knowledge doesn't get enough coverage. Maybe it's because most projects will never need it, but when you eventually do it feels like you're just left to yourself
- rkwasny 3y ago"With limitless databases come limitless costs" (c)
- jaymce 3y agolimitless is hyperbole
- deleted 3y ago[deleted]
- haxor_ 3y agoIt mentions it can scale write transactions to millions per second, but I see no mention of how it can scale read capacity?