I had the same thought. Like, I think Aurora is one of the most expensive ways to do this in AWS. But, since this particular set of data is so well-defined, and unlikely to change, roll your own is maybe not crazy. The transactions per second and size don’t seem that huge to me, so as things grow I imagine they can revisit this.
But, since this particular set of data is so well-defined, and unlikely to change, roll your own is maybe not crazy.
I think that’s the trick here. A relational database lets you do a whole bunch of complex operations on all sorts of data. That flexibility doesn’t come for free - financially nor performance-wise!
Given:
engineering chops
a firm idea of the type of data
a firm idea of the possible operations you may want to do with that data
then there’s a whole range of different approaches to take. The “just use Postgresql” guideline makes sense for most CRUD web systems out there. And there are architecture astronauts who will push stuff because they can, not because they should.
Every now and then it’s nice to think about what exactly is needed and be able to build that. That’s engineering after all!
I had the same thought. Like, I think Aurora is one of the most expensive ways to do this in AWS. But, since this particular set of data is so well-defined, and unlikely to change, roll your own is maybe not crazy. The transactions per second and size don’t seem that huge to me, so as things grow I imagine they can revisit this.
I think that’s the trick here. A relational database lets you do a whole bunch of complex operations on all sorts of data. That flexibility doesn’t come for free - financially nor performance-wise! Given:
then there’s a whole range of different approaches to take. The “just use Postgresql” guideline makes sense for most CRUD web systems out there. And there are architecture astronauts who will push stuff because they can, not because they should.
Every now and then it’s nice to think about what exactly is needed and be able to build that. That’s engineering after all!