andras_gerlits

A short Twitter-thread on why and how we redefine clocks to support consistent streaming. There are more detailed articles in there, but I'll post them here also.

Loosely coupled monoliths and where to find them: An article that provides a general overview of the how we fix microservices and other, corporate-sized distributed system https://medium.com/p/a481d617a0a1

Microservices can be simple — if we let them: The benefits of running such a setup for distributed systems https://medium.com/p/a481d617a0a1

Science-paper for those who want all the details: https://www.researchgate.net/publication/359578461_Continuou...

Also, this isn't entirely true. The transactions can clobber each other and they don't need to be serialized by the transaction-coordinator, but each node can only be single-threaded.

The presentation explains most of it, the whitepaper explains everything, if you're curious.

Also, you can scale the number of transaction-handling nodes to your hearts content. Besides, it supports fully consistent follower-reads by following its own definition of time and potentially skewing the client API's transaction time-window (thereby fitting even strict consistency).

I also talked about this at a conference https://www.youtube.com/watch?v=uCu27LEW2UU

Yes, it does. Well, it's not a database, but it does :).

The original whitepaper describes each mechanism through which different aspects of the SQL standard can be implemented, it's linked on the bottom of our website and from the article.

http://dianemodb.com

I'm planning on releasing a prototype as open source in a few months. I'm also planning on releasing my patent into the public domain.

Sorry, let me clarify. Tweeted to them at the time. So, back in May.

I've published this article 5 months ago. Mine doesn't require global consensus for all commits, just local one and it works from there.

What's even more annoying is that I tweeted this article to them and they didn't say anything.

https://medium.com/p/optimistic-acid-transactions-4f193844bb...

I have a whitepaper about scalable consistency guarantees using optimistic transactions. It should solve these very problems.

https://medium.com/@andrasgerlits/optimistic-acid-transactio...

Well yes, technically. Correct me, but wouldn't locks be bottlenecks when scaling databases? Our solution promises the option of a single global database schema, since increasing the number of concurrent transactions wouldn't hurt performance.

The title is a link. As far as I know, all the databases you've listed are synchronous, lock based solutions, so a single schema can't be grown to any size. Ours can.

We recently published our paper on the first properly ACID-capable, scalable SQL solution we know of. We have worked on it for years, but we are happy with it now.

We'll give you a 1 000 € if you can disprove our paper's claims. That is, you can show that a theoretical element supporting our claim of being a scalable database with SQL-compatible consistency guarantees or the proposed combination of these elements have a fundamental flaw in it.