You are raising a very valid point. You should always carefully consider pros and cons before choosing a third party provider.
The primary reason to build your product on Graphcool is speed of execution. Being able to deliver value quickly is important not just to startups, but also increasingly to enterprises getting squeezed in their core market. This is the reason companies adopt Graphcool.
We acknowledge the fear of lock-in. This is why we support open source GraphQL servers and work on standardising your project configuration as much as possible. For example, today we released the new Graphcool CLI that allows you to configure your project using the open IDL specification (https://www.graph.cool/docs/faq/graphql-idl-schema-definitio...) We also make it very easy to export all your data - either as json, using the api or as a raw sql dump.
Does that answer your question?
This is something we are planning to support. We have two approaches, and I'm curious to hear what would work best for you.
1) Add an integration for selectively syncing data to s3. This would work very similar to the Algolia integration and allow you to transform the shape of your data. Tools like Athena and QuickSight can query directly against s3 buckets, and many other services can import data from s3.
2) Add the ability to provision a read replica and offer direct read-only sql access. This option would carry a higher fixed cost, so would not be appropriate for hobby projects.
BTW saw your talk today at AWS Summit in Berlin. Good job there.
I've had similar questions as you. When it comes to enterprise and data.. that's really the most valuable piece.
If organizations you work with are invested in PostgreSQL I'm working on a GraphQL solution similar to Graphcool with the exception that the storage layer is a plain managed PostgreSQL cluster.
So... you're still locking people in, only to your API rather than your backend?
An automatic GraphQL API generator for Postgres is a potentially awesome tool, in the same way that PostgREST is awesome. But the parent's point is exactly this: "awesome tool" (PostgREST) is awesome, "awesome tool as a service" (Graphcool, Postgraph) is dangerous.
Quite the opposite! It's no different than using Amazon RDS or PostgreSQL in Azure. All of your usual tools for managing and integrating PostgreSQL still work.
The benefit of my system is that it's an easy in to the GraphQL world. You integrate all of your data and services via boring, old PostgreSQL and it just works. My stack takes care of caching, analytics, integration, scaling, etc.
GraphQL is an emerging API specification that, I believe, will ultimately supplant REST in the long term.
> "awesome tool" (PostgREST) is awesome, "awesome tool as a service" (Graphcool, Postgraph) is dangerous.
Are you implying that on-prem software is the only way?
I'm stating that having the option to switch to on-prem is extremely important for your business plan. It puts a hard ceiling on how much your cloud provider can squeeze you for.
We offer the ability to host Graphcool in your own AWS account. This gives you complete control of your infrastructure, but also transfers the burden of maintenance and operations to you. Please get in touch if you are interested in learning more about this option.
Who wants to trust the most valuable part of their product to a third party start up that has a lot of potential to disappear from under your feat, is hard to move away from and might not be flexible enough to incorporate all your future use cases? I can't imagine selling this to any company I ever worked for.