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!
They never would have been able to get the same performance from any solution that incorporates a general purpose database.
Their requirements/explicitly-not-required-ments include that it's fine to drop 1s of data. That would be an insane proposition for any other database. Also their read/write rates and latency requirements are unusual to say the least.
It's the same thing as tiger beetle. Ridiculously narrow domains allow for ridiculous performance improvements compared to of-the-shelf solutions.
I'm really excited to see what forks of tiger Beatle for other domains look like. They, supposedly, built it to be able to modify the state machine to other data schemes, but that code mostly just made realize I had no idea what I was looking at.
As soon as someone makes a KV on it, I'm tried to have be my ETCD database
For anyone seeking to write their own database, I have one recommendation: the Tokyo Cabinet Library.
Tokyo Cabinet abstracts away all the needs of writing your own serializers and deserilizers for binary formats. You can have hashtable databases , B+ trees and everything else all prepared for you under one roof.
Of course that is if you have brain, and don't use a text storage format like JSON. If you use shit like JSON and YAML --- and add potentially hundreds of millisceonds of parsing time just to serialize data from text into machine-readable binary, then please submit your name and address to my council so we can get rid of you when we own the world.
Cleansing of the undesirables aside (seriously, give me ONE good thing about text storage formats! They are EXCHANGE formats, not STORAGE formats!), Tokyo Cabinet is written in C so you can easily bind it with SWIG. But there's probably bindings around if you look.
It seems like features would be mainly additional key/values like temperature, humidity, etc. This wouldn't really change the underlying infrastructure greatly but still give good enhancements to certain customers.
They're just storing doubles in their own format too.
I'm not sure if they even need any spatial lookups on the data, they didn't mention anything about that in the article. Maybe they do that in-memory?