

Rate our startup: Git for databases - matc
http://chronicdb.com

======
pacemkr
This 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.

------
endeavor
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.

------
simonbrown
I'm getting mixed content errors on the checkout page for the file:

<http://chronicdb.com/system/files/images/front_pattern.png>

------
pie
Is this a remote proxy to a local database? API-oriented development may be a
flexible model, but how does this yield acceptable performance?

