15 ms·
Saving cloud costs by writing our own database
- nikonyrh 3y agoVery interesting, it must feel great to get to apply CS knowledge at work, rather than writing basic CRUD apis / websites.
- hasmanean 3y agoStick the gps data in a binary file. Store then filename in the database record.
- icsa 3y agoHow is it possible to save more than 100% ?
- wolframhempel 3y agoFair, should be 98%. Can't change the title anymore though
- jbverschoor 3y agoAws credits
- jayd16 3y agoMove from the cloud to on-prem and then sell extra availability.
- olddustytrail 3y agoIsn't it obvious?! 1. Write your own database 2. ??? 3. Profit!
- aclatuts 3y agoReceive a license fee from someone else for using your software!
- helpmefindpurp 3y ago[dead]
- MuffinFlavored 3y ago> We want to be able to handle up to 30k location updates per second per node. They can be buffered before writing, leading to a much lower number of IOPS. > This storage engine is part of our server binary, so the cost for running it hasn’t changed. What has changed though, is that we’ve replaced our $10k/month Aurora instances with a $200/month Elastic Block Storage (EBS) volume. We are using Provisioned IOPS SSD (io2) with 3000 IOPS and are batching updates to one write per second per node and realm. I would be curious to hear what that "1 write per second" looks like in terms of throughput/size?
- zaroth 3y agoWell they said ~40 bytes per update, so 30k * 40 = 1.2MB/sec… so quite trivial. They also said 30GB per month which works out to 0.7MB/sec if load is perfectly constant.
- MuffinFlavored 3y ago> we’ve replaced our $10k/month Aurora How does 0.7MB/sec end up costing $10k/mo in a hosted database? Can you not achieve 1MB/sec of "queued writes" or something clever against SQLite?
- speedgoose 3y agoSQLite in WAL mode would manage for sure.
- sgarland 3y agoThat’s with their delta-compressed format. Postgres isn’t that. An empty row on its own is 24 bytes. In PostGIS, a point is 32 bytes. If you implemented it with two floats instead, that’s still 16 bytes. A timestamp is 8 bytes. Assuming a bigint PK (8 bytes) and perhaps an int tenant id (4 bytes), that’s at best 60 bytes per row, ignoring any alignment buffering. Likely more. If they’re instead using something more random as a PK, like a UUIDv4, the page splits alone will bloat that well past the raw storage. Similarly, presumably they’re indexing at least one other column, so add that to the overhead.
- nicechianti 3y ago[dead]
- awinter-py 3y agowe have invented write concern = 0
- RHSeeger 3y ago> we’ve replaced our $10k/month Aurora instances with a $200/month Elastic Block Storage (EBS) volume. Without any intent to insult what you've done (because the information is interesting and the writeup is well done)... how do the numbers work out when you account for actually implementing and maintaining the database? - Developer(s) time to initially implement it - PjM/PM time to organize initial build - Developer(s) time for maintenance (fix bugs and enhancement requirements) - PjM/PM time to organize maintenance The cost of someone to maintain the actual "service" (independent of the development of it) is, I assume, either similar or lower, so there's probably a win there. I'm assuming you have someone on board that was on charge of making sure Aurora was configured / being used correctly; and it would be just as easier if not easier to do the same for your custom database. The cost of 120,000/year for Aurora seems like it would be less than the cost of development/organization time for the custom database. Note: It's clear you have other reasons for needing your custom database. I get that. I was just curious about the costs.
- donohoe 3y agoI came here to ask the same question. If this db requires 1 full-time developer then the cost would immediately be not worth it (assuming salary + benefits > $120k/yr) As you say, without details it’s hard to know if this was a good idea.
- loftsy 3y agoApache Cassandra could be a good fit here. Highly parallel frequent writes with some consistency loss allowed.
- bawolff 3y agoKind of misleading to not include the cost of developing it yourself. I think everything is cheaper than cloud if you do it yourself when you don't count staffing cost.
- benrutter 3y agoYeah and for most companies without a huge supply of developers the financial risk of having all your stuff blitzed when your home spun solution fails.
- kaladin_1 3y agoI love the attitude, we didn't see a good fit so we rolled ours. Sure it won't cover the bazillion cases the DBs out there do but that's not what you need. The source code is small enough for any team member to jump in and debug while pushing performance in any direction you want. Cudos!
- INTPenis 3y agoThat is such an insane headline. You might as well say "we saved 100% of cloud costs by writing our own cloud".
- yunohn 3y agoThis is more a bespoke file format than a full blown database. It’s optimized for one table schema and a few specific queries. Not a negative though, not everything needs a general purpose database. Clearly this satisfies their requirements, which is the most important thing.
- Kalanos 3y agoExactly. There are a hundred questions that come to mind like how does it handle concurrent writes, sharding, views. https://en.wikipedia.org/wiki/Database#Database_management_system https://en.wikipedia.org/wiki/Database#Database_management_s... I'm sure they learned a lot, but probably a waste in the long run
- yau8edq12i 3y agoWasn't this already discussed here yesterday? The main criticism of the article is that they didn't write a database, they wrote an append-only log system with limited query capabilities. Which is fine. But it's not a "database" in the sense that someone would understand when reading the title.
- throwaway63467 3y agoWhy isn’t that a database? In my understanding a DB needs to be able to store structured data and retrieve it, so not sure what’s missing here? Many modern DBs are effectively append only logs with compaction and some indexing on top as well as a query engine, so personally I don’t think it’s weird to call this a DB.
- hmottestad 3y agoI don’t know what point you are really trying to make. At uni the DBMS that everyone learns in their database course is an SQL database. The database part is technically just a binary file, but it’s not what people usually mean when they say they need a database for their project. Just like a search engine doesn’t have to be anything more than indexOf and a big text file. It’s just not very useful to think of it like that.
- Symbiote 3y agoYou're describing a relational database management system, which is a specific type of software implementing a specific type of database.
- didgetmaster 3y agoI agree. Is there an industry accepted definition of what a system must do before it can be called a database? I also wrote a KV system to keep track of metadata (tags) for an object store I invented. I discovered that it could also be used to create relational tables and perform fast queries against them without needing separate indexes. I started calling it a database and many people complained that I was misusing the term because it can't yet do everything that Postgres, MySQL, or SQLite can do.
- Simon_ORourke 3y agoI've no doubt this is true, however, anyone I've ever met who exclaimed "let's create our own database" would be viewed as dangerous, unprofessional or downright uneducated in any business meeting. There's just too much can go badly wrong, for all the sunk cost in getting anything up and running.
- democracy 3y agoDepends on their meaning of a "database"
- Simon_ORourke 3y agoTrue, if it's some limited in-memory key-value store then that's a lot more readily implemented than something resembling Oracle's latest enterprise offering, and potentially could fall under the umbrella of it being a "database".
- mavili 3y agoThat is such a problem in today's world. Of course you don't want to re-invent the wheel and all that, but we must be open to the idea of having to do it. Innovation stagnates if people suggesting redoing something are immediately seen as "dangerous, unprofessional or downright uneducated"
- MaKey 3y agoI think the issue is that you rarely get to see a neat new solution to a given problem. Usually you'll see some kind of half-baked attempted solution that's worse than the already existing alternatives.
- mavili 3y agoYes, but what I'm describing is the problem of not even listening to the idea of a new attempt.
- kikimora 3y ago
- endisneigh 3y agoIt would be interesting to see a database built from the ground up for being trivial to maintain. I use managed databases, but is there really that much to do for maintaining a database? The host requires some level of maintenance - changing disks, updating the host operating system, failover during downtime for machine repair, etc. if you use a database built for failover I imagine much of this doesn’t actually affect the operations that much assuming you slightly over provision. For a database alone I think the work needed to maintain is greatly exaggerated. That being said I still think it’s more than using a managed database, which is why my company still does so. In this case though, an append log seems pretty simple imo. Better to self host.
- the_duke 3y agoI don't know what geospatial features are needed, but otherwise time series databases are great for this use case. I especially like Clickhouse, it's generic but also a powerhouse that handles most things you throw at it, handles huge write volumes (with sufficient batching), supports horizontal scaling, and offloading long-term storage to S3 for much smaller disk requirements. The geo features in clickhouse are pretty basic, but it does have some builtin geo datatypes and functions for eg calculating the distance.
- zinodaur 3y agoVery cool! When I started reading the article I thought it was going to end up using an LSM tree/RocksDB but y'all went even more custom than that
- fifilura 3y agoWould building a data lakehouse be an option? Stream the events to s3 stored as Parquet or Avro files, maybe in Iceberg format. And then use Trino/Athena to do the long term heavy lifting. Or for on-demand use cases. Then only push what you actually need live to a Aurora.
- bsaul 3y agoI had a similar idea (except using kafka) : have all the nodes write to a kafka cluster, used for buffering, and let some consumer write those data in batch, into whatever database engine(s) you need for querying, with intermediate pre-processing steps whenever needed. This lets you trade latency for write buffering, while not loosing data thanks to kafka durability guarantees. What would you use for streaming directly to s3 in high volumes ?
- fifilura 3y agoYeah kafka would handle it, except in my experience i would like to avoid kafka if possible, since it adds complexity. (Fair enough it depends on how precious your data is, if it is acceptable to loose some of it if a node crashes) But somehow they are ingesting the data over network. Would writing files to s3 be slower than that? Otherwise you don't need much more than a RAM buffer? Edit: to be clear, kafka is probably the right choice here, it is just that kafka and me is not a love story. But it should be cheaper to store long term data in s3 than storing it in kafka, right?
- diziet 3y agoAs others had mentioned, probably hosting your own clickhouse instance could yield major savings while allowing for much more flexibility in the future for querying data. If your use case can be served by what clickhouse offers, gosh is it an incredibly fast and reliable open source solution that you can host yourself.
- kumarm 3y agoI have built similar system in 2002 using JGroups (JavaGroups at the time before open source project was acquired by JBoss) while persisting asynchronously to DB (Oracle at the time). Our scale even in 2002 was much higher than 13,000 vehicles. The project I believe still appears in success story on JGroups website after 20+ years. I am surprised people are writing their own databases for location storage in 2024 :). There was no need to invent new technology in 2002 and definitely not in 2024.
- _xivi 3y ago> There was no need to invent new technology in 2002 and definitely not in 2024. Sure we have had roads for hundreds of years but they're not the same ones we have today, even though it's the same concept and function. You can't just take advantage of the technology we have today and at the same time refuse to acknowledge it and hand-wavingly claim it was just the same in '02. It's easy to say so about anything if we're going to conveniently gloss over the details. Believe it or not, many technologies that changed the world and we depend on today actually have origin stories similar to the one shared in the article. Many of them started as custom internal tools that I imagine you would've been similarly critical towards them for trying to invent new technology needlessly.
- jrockway 3y agoEveryone seems fixated on the word database and the engineering cost of writing one. This is a log file. You write data to the end of it. You flush it to disk whenever you've filled up some unit of storage that is efficient to write to disk. Every query is a full table scan. If you have multiple writers, this works out very nicely when you have one API server per disk; each server writes its own files (with a simple mutex gating the write out of a batch of records), and queries involve opening all the files in parallel and aggregating the result. (Map, shuffle, reduce.) Atomic: not applicable, as there are no transactions. Consistent: no, as there is no protection about losing the tail end of writes (consider "no space left on device" halfway through a record). Independent: not applicable, as there are no transactions. Durable: no, the data is buffered in memory before being written to the network (EBS is the network, not a disk). So with all of this in mind, the engineering cost is not going to be higher than $10,000 a month. It's a print statement. If it sounds like I'm being negative, I'm not. Log files are one of my favorite types of time series data storage. A for loop that reads every record is one of my favorite query plans. But this is not what things like Postgres or Aurora aim to do, they aim for things like "we need to edit past data several times per second and derive some of those edits from data that is also being edited". Now you have some complexity and a big old binary log file and some for loops isn't really going to get you there. But if you don't need those things, then you don't need those things, and you don't need to pay for them. The question you always have to ask, though, is have you reasoned about the business impacts of losing data through unhandled transactional conflicts? "read committed" or "non-durable writes" are often big customer service problems. "You deducted this bill payment twice, and now I can't pay the rent!" Does it matter to your end users? If not, you can save a lot of time and money. If it does, well, then the best-effort log file probably isn't going to be good for business.
- bradleyjg 3y agoIf you only need those things there’s also an off the shelf solution for log files. Time you spend reinventing the wheel is time you aren’t spending finding product-market fit (if you’ve already found it you wouldn’t even consider it because you’d be too busy servicing the flood of customers.) Unless your company is so far past product market fit that it hires qualified applicants by the classfull or whatever-it-is is their product, they have no business coding up custom infra bits. The opportunity cost alone is sufficient argument against, though far from the only one.
- mavili 3y agoThat's called engineering; you had a problem, you came up with a solution THAT WORKS for your needs. Nicely done and thanks for sharing.
- xyst 3y agoThis seems like they rewrote Kafka to me. Even moderately sized Kafka clusters can handle the throughput requirement. Can even optimize for performance over durability. Some limited query capability with components such as ksqldb. Maybe offload historical data to blob storage. Then again, Kafka is kind of complicated to run at these scales. Very easy to fuck up.
- kdazzle 3y agoPlus managed kafka is pretty expensive
- jpgvm 3y agoEh, Kafka isn't easy to fuck up. If anything it's stupidly hard to fuck up assuming you aren't completely incompetent and didn't read up on how it works or the main caveats. I say that because there really isn't much to Kafka in the first place (as long as you aren't including things like Kafka Streams or Kafka Connect etc). Operationally there are some annoying things in OSS Kafka (hot partitions, controller failover slowness pre-KRaft, etc) but it's overall bog simple and easy to work with if you can accept the things it doesn't do (queue-like behavior). I don't love Kafka these days but the fear mongering is a bit much. Sidenote: If you think you want Kafka you should probably check Pulsar first, in most cases you probably want Pulsar or due to changing requirements you would have been better off going Pulsar from the start.
- deleted 3y ago[deleted]
- time0ut 3y agoGood article. > EBS has automated backups and recovery built in and high uptime guarantees, so we don’t feel that we’ve missed out on any of the reliability guarantees that Aurora offered. It may not matter for their use case, but I don't believe this is accurate in a general sense. EBS volumes are local to an availability zone while Aurora's storage is replicated across a quorum of AZs [0]. If a region loses an AZ, the database instance can be failed over to a healthy one with little downtime. This has only happened to me a couple times over the past three years, but it was pretty seamless and things were back on track pretty fast. I didn't see anything in the article about addressing availability if there is an AZ outage. It may simply not matter or maybe they have solved for it. Could be a good topic for a follow up article. [0] https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/ https://aws.amazon.com/blogs/database/introducing-the-aurora...
- SmellTheGlove 3y agoI'm surprised to see the (mostly) critical posts. My reaction before coming to the comments was: - This is core to their platform, makes sense to fit it closely to their use cases - They didn't need most of what a full database offers - they're "just" logging - They know the tradeoffs and designed appropriately to accept those to keep costs down I'm a big believer in building on top of the solved problems in the world, but it's also completely okay to build shit. That used to be what this industry did, and now it seems to have shifted in the direction of like 5-10% of large players invent shit and open source it, and the other 90-95% are just stitching together things they didn't build in infrastructure that they don't own or operate, to produce the latest CRUD app. And hell, that's not bad either, it's pretty much my job. But it's also occasionally nice to see someone build to their spec and save a few dollars. It's a good reminder that costs matter, particularly when money isn't free and incinerating endless piles of it chasing a (successful) public exit is no longer the norm. I get the arguments that developer time isn't free, but neither is running AWS managed services, despite the name. And they didn't really build a general purpose database, they built a much simpler logger for their use case to replace a database. I'd be surprised if they hired someone additional to build this, and if they did, I'd guess (knowing absolutely nothing) that the added dev spends 80% of their time doing other things. It's not like they launched a datacenter. They just built the software and run it on cheaper AWS services versus paying AWS extra for the more complex product.
- deleted 3y ago[deleted]
- CapeTheory 3y agoIt's amazing what can happen when software companies start doing something approximating real engineering, rather than just sitting a UI on top of some managed services.
- deleted 3y ago[deleted]
- zX41ZdbW 3y agoSounds totally redundant to me. You can write all location updates into ClickHouse, and the problem is solved. As a demo, I've recently implemented a tool to browse 50 billion airplane locations: https://adsb.exposed/ https://adsb.exposed/ Disclaimer: I'm the author of ClickHouse.
- whalesalad 3y agoHeh, my first thought reading this post was “did you try clickhouse”
- kroolik 3y agoI could be missing something, but I can't really wrap my head around "unlimited paralelism". What they say is that the logic is embedded into their server binary and they write to a local EBS. But what happens when they have two servers? EBS can't be rw mounted in multiple places. Won't adding the second and more servers cause trouble like migrating data when new server joins the cluster, or a server leaves the cluster? I understand Aurora was too expensive for them. But I think it is important to note their whole setup is not HA at all (which may be fine, but the header could be misleading).
- klohto 3y agoEBS can be multi attached for a long time now, no perf impact
- kroolik 3y agoOh thanks! Always thought it was what EFS was for. They are still limited to the same AZ, so no multi AZ redundancy.
- klohto 3y agoyea, multi AZ failover would be an issue but I assume they don’t care that much. you could spinup new EBS from the backup when the first region fails or keep a warm copy there, but seems like a lot of extra engi work.
- trebecks 3y agoi got caught up on that statement too. i interpreted it as they can spin up more servers with their own volumes but thats not really 1 ebs volume anymore. maybe at their current load they only need 1? the op mentioned copying stuff to s3 at a certain size so it sounds like the disk isn't very big at any moment. i don't think there would be much to do if another server joins. > Amazon EBS offers a higher durability volume (io2 Block Express), that is designed to provide 99.999% durability with an annual failure rate (AFR) of 0.001%, where failure refers to a complete or partial loss of the volume. if they take snapshots often enough to feel comfortable with that low failure rate, it does seem kind of reasonable to me. really low risk of a given volume failing.
- afro88 3y agoThese two sentences don't work together: > [We need to cater for] Delivery companies that want to be able to replay the exact seconds leading up to an accident. > We are ok with losing some data. We buffer about 1 second worth of updates before we write to disk Impressive engineering effort on it's own though!
- bevekspldnw 3y ago“We are running a cloud platform that tracks tens of thousands of people and vehicles simultaneously” …that’s not something to brag about.
- sneak 3y agoWhy, because you think the surveillance implies that it’s nonconsensual and thus unethical, or the very small scale (<100k clients) means this isn’t actually a very difficult engineering challenge?
- rvba 3y ago> So - given that we don’t know upfront what level of granularity each customer will need, we store every single location update. Maybe Im cynical but interesting that "the business" didnt start to check it to cut costs. I know that customers love this feature. Cynically I can see it costing more, so some customers would drop in. Also it looks they rewrote a log / timeseries "database" / key value store? As pthers mention sounds like reinventing the wheel to get a cool blog post and boost career solving "problems".
- deleted 3y ago[deleted]
- rad_gruchalski 3y ago> we’ve replaced our $10k/month Aurora instances with a $200/month Elastic Block Storage (EBS) volume Reminds me how I implemented mssql active-active log replication over dropbox shares back in 2010 to synchronise two databases in the Us and in the UK. Worked perfectly fine except of that one hurricane that took them out for longer than 14 days. This was more than the preconfigured log retention period.
- remram 3y agoThey mention all those features of databases, presenting them as important: > Databases are a nightmare to write, from Atomicity, Consistency, Isolation, and Durability (ACID) requirements to sharding to fault recovery to administration - everything is hard beyond belief. Then talk about their geospatial requirements, PostGIS etc, making it seems they need geospatial features ("PostGIS for geospatial data storage" -- wtf? you need PostGIS for geospatial query not merely storage...) In reality, they did not require any of the features they mention throughout the article. What a weird write-up! I guess the conclusion is "read the F*-ing specs". Don't grab a geospatial DBMS just because you heard the words "longitude" and "database" once.
- physicles 3y agoIt’s like SpaceX’s development process. Step 1: “make your requirements less dumb”
- exabrial 3y agoWhy is everyone dead set on “must use aws” these days? One can cut their cloud costs by 100x with colo. And if you write your own db as they did here, it can 100% take advantage of your setup.
- halayli 3y agoThey talk about what they store but zero mention on their retreival requirements.
- trebecks 3y agoif i'm reading the op right, they kind of use ebs as a buffer for fresh data until it ages out to s3. they use a "local" disk to hold the stuff used by the queries that people actually make and the queries run quick. they let the old stuff rot in s3 where its almost never used. that sounds like a good idea to save money plus the stuff that's done often is fast. the ebs slas look reasonable to a non expert like me and you can take snapshots. it sound like you need to be careful when snapshotting to avoid inconsistencies if stuff is only partially flushed to disk. so you'd need to pause io while it snapshots if those inconsistencies matter. that sounds bad and would encourage you to take less frequent snapshots...? you also pay for the snapshot storage but i guess you wouldn't need to keep many. i like that aws defines "SnapshotAPIUnits" to describe how you get charged for the api calls. with aurora, it looks like you can synchronously replicate to a secondary (or multiple secondaries) across azs in a single region. it sounds nice to have a sync copy of stuff that people are using. op says the'yre ok with a few seconds of data loss so i'm wondering how painful losing a volume right before taking a snapshot would be. i wonder if anything off the shelf does something similar. it sounds like people are suggesting clickhouse. i saw buffer table in their docs and it sounds similar https://clickhouse.com/docs/en/engines/table-engines/special/buffer https://clickhouse.com/docs/en/engines/table-engines/special.... it looks like it has stuff to use s3 as cold storage too. i even see geo types and functions in the docs. i've never used clickhouse so i don't know if i'm understanding what i read, but it sounds like you could do something similar to whats described in the post with clickhouse if the existing geo types + functions work and you are too lazy to roll something yourself.
- pheatherlite 3y agoHow fast can reads be thou? Even if skipping along a fixed offset, reading 4 byte identifiers to filter out location updates for vehicles, that's still a sequential scan of a massive file. Wouldn't this read issue become a choking point to a degree that would make growth a curse? Then you get into weird architectures that exist solely to facilitate predigested reads?
- tshanmu 3y ago"Of course, that’s an unfair comparison, after all, Postgres is a general purpose database with an expressive query language and what we’ve built is just a cursor streaming a binary file feed with a very limited set of functionality - but then again, it’s the exact functionality we need and we didn’t lose any features."
- mdaniel 3y agoAnytime I hear "we need to blast in per-second measurements of ..." my mind jumps to "well, have you looked at the bazillions of timeseries databases out there?" Because the fact those payloads happen to be (time, lat, long, device_id) tuples seems immaterial to the timeseries database and can then be rolled up into whatever level of aggregation one wishes for long-term storage It also seems that just about every open source "datadog / new relic replacement" is built on top of ClickHouse, and even they themselves allege multi-petabyte capabilities <https://news.ycombinator.com/item?id=39905443 https://news.ycombinator.com/item?id=39905443> OT1H, I saw the "we did research" part of the post, and I for sure have no horse in your race of NIH, but "we write to EBS, what's the worst that can happen" strikes me as ... be sure you're comfortable with the tradeoffs you've made in order to get a catchy blog post title
- robertlagrant 3y ago> but "we write to EBS, what's the worst that can happen" strikes me as ... be sure you're comfortable with the tradeoffs you've made in order to get a catchy blog post title In what way?
- freeone3000 3y agoEBS latency is all over the place. The jitter is up to the 100ms scale, even on subsequent IOPS. We’ve also had intermittent failures for fsync(), which is a case that should be handled but is exceptionally rare for traditionally-attached drives.
- RHSeeger 3y agoThe author does note in the writeup that they are comfortable with some (relatively rare) data loss; like server failure and the like. Given their use cases, it seems like the jitter/loss of EBS wouldn't be too impactful to them.
- solatic 3y agoThere's different kinds of data loss. There's data loss because you lose the whole drive; because you lost a whole write; because a write was only partially written. Half the problem with NIH solutions is, what happens when you try to read from your bespoke binary format, and the result is corrupted in some way? So much of the value of battle-tested, multi-decade-old databases is that those are solved problems that you, the engineer building on top of the database, do not need to worry about. Of course data loss is alright when you're talking about a few records within a billion. It is categorically unacceptable when AWS loses your drive, you try to restore from backup, the application crashes when trying to use the restored backup because of "corruption", the executives are pissed because downtime is reaching into the hours/days while you frantically try to FedEx a laptop to the one engineer who knows your bespoke binary format and can maybe heal the backup by hand except he's on vacation and didn't bring his laptop with him.
- avidphantasm 3y agoSeems like DuckDB or TileDB backed by S3 may meet your needs and be a lot cheaper than Aurora.
- brianhama 3y agoHonestly, this doesn’t seem like that high of requirements. There are tens of thousands of companies that are doing more spatial data processing and are using standard cloud databases just fine.
- rstuart4133 2y agoA lot of people here are making very confident sounding assertions, yet some as saying it's just an append only log file and some imply it's sharded. Something everyone does agree on is they are very vague about what geospartial features they need. The one thing they do say is "no ACID". That implies no b-trees, because an unexpected stop means a corrupted b-tree. Perhaps they use a hash instead, but it would have to be a damned clever hash tree implementation to avoid the same problem. Or perhaps they just rebuild the index after a crash. Even a append only log file has to be handled carefully without ACID. An uncontrolled shutdown in more file systems will at leave blocks of nulls in the file and 1/2 written blocks if they cross disk block boundaries. It's a tantalising headline, but after reading the 1,200 words I'm none the wiser on what they built or whether it meets their own specs. A bit of a disappointment.