In our case we set up a dedicated cheap database server only for ChartIO. Then we have a script that copies to it analytics data from our production servers every few hours (while also anonymizing what needs to be just to be extra safe).
This is a good approach. I work with ERP systems for large companies, and it's typical to separate the transactional database (OLTP) from the analytics database (OLAP). There's usually a replication process to copy transactions into the reporting system.
Great use case! We don't support an API that you can push data to, but that's because whatever API we build, it would never be easier to learn or have as much language support than just spinning up a PostgreSQL instance and writing the data to it. Quite a few of our customers use us this way.
You guys should really suggest this approach in the setup guide (it can be phrased in a way not to scare potential users). The alternative of directly accessing production database servers is really risky.
Agreed. I'll work on it.
This seems like what you'd do just to protect your production server from some crazy load/etc. issues from analysis, too. I can't imagine giving read-only access to a core rw database server to anything which didn't need it.
+1 for getting non-operational stuff off of the production servers. In my opinion, production servers should be left untouched by analytics and what not. I'd prefer not tying up resources that could better serve customers.
Yep. That's the kind of approach I'd like to see Chartio recommending (or at least, providing suggestions for).