@timshuwy , @Vaibhav_Vohra , thank you and your team for gathering all our feedback the past couple weeks. We may be rude and bitter at times but we very much appreciate your efforts and participation on the forum!
I made a post that I’m sure got buried last week so I just wanted to try calling it out in a separate thread to get more eyes on it, hoping it can be addressed as part of Epicor’s guidance on recommended development patterns going forward:
Basically my point is that oftentimes the right tool for data intensive jobs is doing things at the database (SQL) level as opposed to bubbling things up through the application layer. That said I am open to being convinced that “most performant” and “right tool” are not necessarily the same thing in today’s world.
I do have a specific question about Epicor Data Analytics (EDA), which we’re using currently On Prem. EDA pulls our ERP data via SQL scripts stored on the DB server, which we are able to modify to meet our BI needs and enhance the out of the box package. Does EDA work the same way in SaaS environments? Is there an ability to modify the SQL scripts? If so does it require Cloud Ops team to push changes? I assume similar questions apply to Grow but I’m not familiar with exactly how that one works.
Or, if we choose to integrate a 3rd party BI, will the recommendation be to pull everything out via BAQ from the application layer? Or is this where the Read Only database subscription comes in? With the RO DB, is there an ability to write stored procs and schedule jobs? Or would we need a local SQL instance to house any scripts / run jobs which then hit the Kinetic RO DB over the Internet? (at which point we are probably better off just going through the application layer)
Thanks for highlighting this topic. I have a related question based on a real customer scenario.
On-prem, the customer uses SQL replication from the production database to a separate reporting database, which is consumed by multiple third-party reporting tools and Excel with complex scripting.
This approach works well because reporting runs directly on the replicated database, is high-performance, and does not impact production users.
The customer has a large number of business-specific reports, and reporting requirements vary widely across teams.
As customers move to Epicor SaaS, we would like clarity on:
What is the recommended SaaS alternative to on-prem SQL replication for reporting?
Can the Read-Only DB support data-intensive reporting similar to a replicated on-prem database?
For customers with many third-party reports, should data be accessed via BAQs/REST APIs or direct RO DB access, and what are the performance trade-offs?
How should customers with hundreds of existing reports plan their migration to SaaS without losing performance or flexibility?
Any guidance on Epicor’s recommended architecture and best practices would be appreciated.
Great questions, and thanks for taking the time to lay out the why behind them. I appreciate the thoughtful framing around “right tool vs. most performant”… that’s exactly the discussion we should be having as guidance evolves.
I want to be clear up front about my role here: I’m not a SQL, EDA, or GROW expert, so I don’t want to pretend otherwise or give you half-answers. What I can do is help frame how Epicor is thinking about these patterns at a high level and then pull in the right people to fill in the technical specifics.
At a high level, part of the answer for data-intensive, read-heavy workloads in SaaS is the Read-Only SQL database offering. That exists specifically to support reporting, analytics, and BI-style use cases without pushing that load through the application layer. Epicor has published guidance around this offering, and it’s intended to be the primary path when customers need direct SQL access in a SaaS environment.
That said, this is also where the distinctions between our analytics options matter:
EDA (Epicor Data Analytics) – This is a managed analytics solution with defined extraction and modeling patterns. SaaS EDA does not behave the same as on-prem EDA, particularly around direct SQL script modification, and that’s an important difference that deserves a precise answer.
GROW – This follows a different model entirely, extracting data into a separate analytics database that GROW manages. It avoids direct dependency on the ERP database, but it also comes with its own rules about extensibility and customization.
Read-Only SQL DB – This sits closer to the metal and is intended for customers or partners who want to bring their own BI tools and do heavier analytical lifting themselves, within supported constraints.
Rather than speculate on the exact boundaries of what can and cannot be customized in EDA or GROW (especially in SaaS), I’m going to pull in people who live and breathe this every day.
@JenTrifty (Jennifer Triftshauser) has her team members who specialize in EDA, GROW, and the Read-Only SQL offering and we will reach out to them to give you authoritative answers on:
How EDA behaves in SaaS vs. on-prem
What customization options exist (and don’t)
How GROW fits into this decision space
Practical guidance on when to use RO SQL vs. application-layer access
I’ll also make sure relevant Epicor documentation is referenced so you have something concrete to anchor on, not just forum replies.
Thanks again for raising this… these are exactly the kinds of questions that help us sharpen both the platform and the guidance around it.