I visited your site and, to be honest, to me it is unclear why I would should choose your solution over for example PostgreSQL. * "Fast": up to 130.000 TPS (in

I visited your site and, to be honest, to me it is unclear why I would should choose your solution over for example PostgreSQL. * "Fast": up to 130.000 TPS (inserts apparently) sounds a lot, but I'm not sure it is, see for example http://akorotkov.github.io/blog/2016/05/09/scalability-towards-millions-tps/ http://akorotkov.github.io/blog/2016/05/09/scalability-towar.... Maybe I'm comparing apples with oranges, but since your statement is not backed up by anything I can verify myself this does not stand out as a feature to me. It also sits in a spot where it is too high for startups to be relevant and too low for potential global players since it seems to be the limit, and as you can see in the link, even PostgreSQL provides a way to scale way beyond that number. Maybe your solution can be clustered, but I see no mention of this. * If I need an in-memory DB, I usually need it for caching or for tests. The first use case is mostly covered by Redis (but I admit being able to use SQL for cache retrieval has some appeal), the second use case (tests) is questionable, since I either use your DB all the way or I'd have a separate DB for tests, which is a not very inviting thing to have to me. * You state that your DB is not only in-memory only but also can?(is always?) be persisted via Redis. How is that working, what are consequences for conflicts, transactionality etc.? I don't find much about this topic, just a reference that it is "[on] par with incumbent databases such as Postgres or MySQL". * Lastly, you should mention that the SQL dialect is SQlite. I'd hate having to learn another SQL dialect and I guess many of my peers would do the same. I'd suggest you switch the focus from "fast in-memory DB" to "Run SQL queries on cached data to allow more leeway to your real SQL database". This sounds appealing to me, provided there are some real-life examples how this can work (e.g. a demo project). If you go this way, I'd also probably also drop (or not focus) "being able to persist cached data" to automating cache-refreshes consistently, since this would probably be needed.