Rate our startup: Git for databases
chronicdb.comThis is actually very interesting. I think you guys should do a short video describing the problem and how your product solves it. It's a little difficult to process how your product falls into a "typical" workflow.
I _know_ I was looking for something like this before. I think db versioning is a huge pain. Are migration files really the best we can do? I don't think so. You product seems to be trying to solve that problem. I think you need to communicate that "quicker." A short video might do that. It doesn't have to be fancy, just show it in action.
I wish you guys would put up a "How It Works" page with more detail. I saw the FAQ under Pricing, but that's not the place I would expect to find all the info.
- Like pie asked, is this a remote proxy?
- What happens if I start a transaction and then the storage engine detects a deadlock and rolls back the transaction?
- What DBs does it work with? I think you say any DB but I have a hard time believing that.
- What is performance like?
- Zero downtime? That sounds like snake oil.
- Can I have an internally hosted solution?
- Shouldn't this be implemented at the storage engine level?
Anyway it sounds very interesting but the devil is in the details.
I'm getting mixed content errors on the checkout page for the file:
Is this a remote proxy to a local database? API-oriented development may be a flexible model, but how does this yield acceptable performance?