Hi, we are thinking about switching to Coda (via the Coda API) for our database for our simple website, instead of sending data to our MySQL database, and then to Coda, in order to have a single source of truth for all our user data.
Did anyone try it ? Did you have any performance issue ?
Hi @Blaise_d_Estais,
welcome to Coda Community! 
I’d be a bit cautious to use Coda as a database, unless it is perfectly clear what are your boundaries and expectations.
Coda is a smart document so well designed that it’s straightforward to come up with app capabilities, so you can conjugate data model and visual interface quite easy.
However, a DB usually offers specific functionalities for a wide variety of data management and it is designed for that purpose.
What is the underlying reason to keep the data in Coda?
Could you outline your use case?
Meanwhile, I believe that @Mario built up something similar and maybe he can better tell pros and cons based on his experience.
Cheers!
Hi @Blaise_d_Estais, welcome to the community 
Thanks for the mention @Federico_Stefanato 
My case is a little different from yours because sadly my doc have been over 125mb since his creation so i’ve never been able to use api with it.
My plan was to make some of the data in the doc available in a wordpress website, to create alternative and nearly limitless layouts and interfaces.
This for doc size and current api limitations evolved into “doc in coda.io as main client and export of some data into external website”
In my case i’ve a scheme based on the coda account of users (it’s like a multi-user app) that should in some ways be “connected” to a login in the external website, to give data to the right users.
So, my use case is a little bit “complicated” in this moment so i’ve post-poned it to a to be definied date, but if you plan on maybe some forms or something more “basic” it probably can be done, as Federico says tell us more about your case 
In this topic @oleg have highlighted that an intermediary passage was suggested to not make key public, but it’s an old post, maybe outdated
Know that if your doc is going to get bigger and bigger you’ll soon have to archive some part of it or trick the size improving columns type and others…
My actual consideration is anyway to not use trick or hack in production docs, to not be forced to re-adapt them at every coda’s update…
If it is like a “personal” project or a small website/mini app, with limited growth, it can be funny to have it on coda, if you do please share your impressions on the process you followed here
There are probably much more hacky users here that have tried something, let’s wait a bit
Thank you very much,
The Headless CMS w/ Coda is a great example thank you !
My use case is we have a website with a simulator, and a salesperson calls back the user.
We would save user data directly in Coda, so that the user can get his sales status in the site, and if he updates his data, sales get the last version.
Usage is mostly one shot, users may come back 2-3 times maximum, so it won’t spam the api and need other customizations.
And one of the primary benefits is always the same : coda as a single source of truth, and single place for data management (if we change a form field, we just update one coda column, no need to update a SQL, plenty of SQL requests, a Zapier and more) !
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.