Rate our startup: Git for databases
chronicdb.com
Rate our startup: Git for databases
1–5 of 5 posts
Re: Rate our startup: Git for databases
#2I'm getting mixed content errors on the checkout page for the file:
Re: Rate our startup: Git for databases
#3This 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.
Re: Rate our startup: Git for databases
#4Is this a remote proxy to a local database? API-oriented development may be a flexible model, but how does this yield acceptable performance?
Re: Rate our startup: Git for databases
#5I 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.