# Cloud Direct SQL Access

**URL:** <https://www.epiusers.help/t/cloud-direct-sql-access/132332>\
**Category:** Kinetic ERP\
**Tags:** kinetic\
**Created:** [January 28, 2026, 6:34pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332 "2026-01-28T18:34:51Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![JasonO](https://www.epiusers.help/letter_avatar_proxy/v4/letter/j/46a35a/32.png) [@JasonO](https://www.epiusers.help/u/JasonO)\
**Post date:** [January 28, 2026, 6:34pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/1 "2026-01-28T18:34:51Z")

</div>

This may have been answered before, but I am having trouble wading through all the similarly worded questions to find the answer.

We are currently On-Prem, for obvious reasons, we are researching what moving to the cloud might look like for us. One of my biggest fears is losing access to the SQL Database directly. Yes, I know there are BAQs, and Yes, I know there is a read-only synched version for local access, but both have SIGNIFICANT drawbacks for some of the solutions we have developed over the years of having the database here.

For example, we have an in-house developed Fulfillment application. It builds a Queue of Consumer orders and prioritizes them and hands them out to Pickers based on time, customer priority, availability, etc. In order to keep this queue accurate for things like Held orders, cancelled orders, or priority changes, etc., it looks at the Epicor SQL Database OrderHed table about every 5 seconds for records to load. This Look is exceptionally efficient and takes on average \<0.3 seconds and places no data locks (of consequence) on the table. Then based on the cursory findings, goes and loads the orders with a slightly deeper look at the table if needed. To do this across the board for our custom apps with BAQs would require approximately 500 BAQs to be created and maintained, and even then I cannot run a BAQ in .3 seconds. The overhead of the app handling the request is significantly greater than SQL Access. The Local Copy is too stagnant and as I read on here, too prone to breaking. If it broke overnight, we could end up with massive fines before someone caught on that it broke and got it fixed. For instance on Black Friday we can easily handle 6,000 orders through this custom application. An hour of dropped orders could easily cause thousands in late ship fines.

All Epicor Transactions are handled through REST calls, we never directly edit or write data into SQL, but we often populate those REST calls from Direct SQL read data. We do not open the SQL Database for general ODBC Access to users, only to Applications controlled by IT.

Anyway, TLDR, I see comments that Epicor discourages Direct SQL Access, but no definitive answer to if it can be done anyway in a Cloud environment (Not multi-Tenant obviously).

---

<div class="post-metadata">

**Author:** ![GabeFranco](https://www.epiusers.help/user_avatar/www.epiusers.help/gabefranco/32/80642_2.png) [@GabeFranco](https://www.epiusers.help/u/GabeFranco)\
**Post date:** [January 28, 2026, 6:40pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/2 "2026-01-28T18:40:42Z")

</div>

No, you cannot do SQL in cloud.

It sounds like things will need to be re-architected based on triggers vs. Polling.

---

<div class="post-metadata">

**Author:** ![Randy](https://www.epiusers.help/user_avatar/www.epiusers.help/randy/32/51539_2.png) [@Randy](https://www.epiusers.help/u/Randy)\
**Post date:** [January 28, 2026, 6:41pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/3 "2026-01-28T18:41:02Z")

</div>

In typical cloud SaaS you have no directed access to the SQL database. There is the read-only and BAQs which both have drawbacks as you said. Integrations are best using REST API calls.

That’s why many, even some of us current SaaS customers, are wanting a compromise to going cloud SaaS via Containers.

---

<div class="post-metadata">

**Author:** ![aosemwengie1](https://www.epiusers.help/user_avatar/www.epiusers.help/aosemwengie1/32/95533_2.png) [@aosemwengie1](https://www.epiusers.help/u/aosemwengie1)\
**Post date:** [January 28, 2026, 6:44pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/4 "2026-01-28T18:44:50Z")

</div>

> [@JasonO](#):
>
> it looks at the Epicor SQL Database OrderHed table about every 5 seconds for records to load

You can do this with the read only database in cloud. Its effectively real time (I have never been able to catch data in the read only database out of sync with the UI).

---

<div class="post-metadata">

**Author:** ![Evan\_Purdy](https://www.epiusers.help/user_avatar/www.epiusers.help/evan_purdy/32/69101_2.png) [@Evan\_Purdy](https://www.epiusers.help/u/Evan_Purdy)\
**Post date:** [January 28, 2026, 6:47pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/5 "2026-01-28T18:47:38Z")

</div>

> [@GabeFranco](#):
>
> It sounds like things will need to be re-architected based on triggers vs. Polling.

I agree with this.

I also question the 500 BAQ comment - unless you have 500 SQL queries. They should map almost 1 to 1. (In fact they have a converter now, but I haven’t used it much..) But I think its a moot point, I don’t think the current design he has is cloud friendly.

---

<div class="post-metadata">

**Author:** ![JasonO](https://www.epiusers.help/letter_avatar_proxy/v4/letter/j/46a35a/32.png) [@JasonO](https://www.epiusers.help/u/JasonO)\
**Post date:** [January 28, 2026, 6:58pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/6 "2026-01-28T18:58:56Z")

</div>

> [@Evan\_Purdy](#):
>
> I don’t think the current design he has is cloud friendly.

Oh, agreed, current design is not Cloud Friendly, as we had always been promised we could have our database On-Prem, till this year.

As to the 500 BAQs, Because we know the impact of pulling too much data, literally every call to the database is for only the exact fields necessary for that call with the best Joins and Filters to encourage the best Index to use to get the data as fast possible with the least amount of resources needed to pull that data, we rely heavily on Execution Plan review and optimizations for these queries. So 1 call to get customer data is just CustID and Name, a different call might also include GroupCode, so 2 different SQL queries used. When poking at the database as much as we do, it needs to be excessively quick or we can easily bring the database server to its knees. To add the overhead of the REST Session alone will add nearly 300% of overhead usage (I have tested it) to our custom applications.

So, yes, we could merge a bunch of those and use a more generic Query in the BAQ to handle more edge cases, to cut down the total number of BAQs it would just cost us more resources. Some of our custom applications could probably handle the slowdown without a huge impact to our users, but others might be devastating.

---

<div class="post-metadata">

**Author:** ![Evan\_Purdy](https://www.epiusers.help/user_avatar/www.epiusers.help/evan_purdy/32/69101_2.png) [@Evan\_Purdy](https://www.epiusers.help/u/Evan_Purdy)\
**Post date:** [January 28, 2026, 7:08pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/7 "2026-01-28T19:08:11Z")

</div>

Have you evaluated the performance of data directives?

---

<div class="post-metadata">

**Author:** ![GabeFranco](https://www.epiusers.help/user_avatar/www.epiusers.help/gabefranco/32/80642_2.png) [@GabeFranco](https://www.epiusers.help/u/GabeFranco)\
**Post date:** [January 28, 2026, 7:09pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/8 "2026-01-28T19:09:51Z")

</div>

Given your requirements, this would be my approach.

- Strip the custom apps down to their business requirements. If past you was nice to future you, you’ve got a somewhat up to date documentation to start from. If not, reverse engineering your past work is fun to call out things like “who did that? it couldn’t have been me…”
- Due to latency/uptime requirements, use a single source of truth. Build this out in Epicor as some combination of a Dashboard/Function/Schedule/Data Directives/Method Directives/BAQ. If your queries are long running, consider running them as cubes or scheduled functions dumping data into a temporary location for later reference. You may consider writing Advanced BPM uBAQ code or using function code against the Db object and tables directly (only for read only things of course) - you can directly affect how the data is chunked up this way
- Sell the labor cost to the higher ups as increasing your reliability and accessibility by reducing/removing IT maintenance costs of the external apps and linking your uptime to Kinetic.

---

<div class="post-metadata">

**Author:** ![JasonO](https://www.epiusers.help/letter_avatar_proxy/v4/letter/j/46a35a/32.png) [@JasonO](https://www.epiusers.help/u/JasonO)\
**Post date:** [January 28, 2026, 9:04pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/9 "2026-01-28T21:04:53Z")

</div>

> [@Evan\_Purdy](#):
>
> Have you evaluated the performance of data directives?

I have not, it would require a very significant rewrite of the way the program functions to get the benefit of that, though researching it will be on my list of things to do if I really can’t get direct SQL Access.

---

<div class="post-metadata">

**Author:** ![Evan\_Purdy](https://www.epiusers.help/user_avatar/www.epiusers.help/evan_purdy/32/69101_2.png) [@Evan\_Purdy](https://www.epiusers.help/u/Evan_Purdy)\
**Post date:** [January 28, 2026, 9:07pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/10 "2026-01-28T21:07:52Z")

</div>

Well, as people mentioned you can get a read only copy for extra $$$ but you are still not going to be accessing it locally so I don’t know how performance compares.

@aosemwengie1 Have you had any opportunity to compare cloud read only db performance to local db?

---

<div class="post-metadata">

**Author:** ![klincecum](https://www.epiusers.help/user_avatar/www.epiusers.help/klincecum/32/100137_2.png) [@klincecum](https://www.epiusers.help/u/klincecum)\
**Post date:** [January 28, 2026, 9:13pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/11 "2026-01-28T21:13:09Z")

</div>

Still waiting on the full details, but that private cloud thing might have some more options.

---

<div class="post-metadata">

**Author:** ![aosemwengie1](https://www.epiusers.help/user_avatar/www.epiusers.help/aosemwengie1/32/95533_2.png) [@aosemwengie1](https://www.epiusers.help/u/aosemwengie1)\
**Post date:** [January 28, 2026, 9:13pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/12 "2026-01-28T21:13:52Z")

</div>

> [@Evan\_Purdy](#):
>
> Have you had any opportunity to compare cloud read only db performance to local db?

Its slow when accessing as a linked server but there should be other ways to get to it that are faster.

---

<div class="post-metadata">

**Author:** ![aosemwengie1](https://www.epiusers.help/user_avatar/www.epiusers.help/aosemwengie1/32/95533_2.png) [@aosemwengie1](https://www.epiusers.help/u/aosemwengie1)\
**Post date:** [January 28, 2026, 9:22pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/13 "2026-01-28T21:22:06Z")

</div>

> [@klincecum](#):
>
> private cloud

Private cloud

Custom cloud

Enterprise

???

---

<div class="post-metadata">

**Author:** ![JasonO](https://www.epiusers.help/letter_avatar_proxy/v4/letter/j/46a35a/32.png) [@JasonO](https://www.epiusers.help/u/JasonO)\
**Post date:** [January 28, 2026, 9:28pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/14 "2026-01-28T21:28:37Z")

</div>

> [@aosemwengie1](#):
>
> Its slow when accessing as a linked server but there should be other ways to get to it that are faster.

Do you know if the slowness is establishing the connection, the round trip of the request is slow, or the processing of the query is slow? I could possibly handle the first two issues with how I manage establishing and maintaining the connection, the third, not much can be done. Ok, if you don’t know, just thought I would check.

---

<div class="post-metadata">

**Author:** ![aosemwengie1](https://www.epiusers.help/user_avatar/www.epiusers.help/aosemwengie1/32/95533_2.png) [@aosemwengie1](https://www.epiusers.help/u/aosemwengie1)\
**Post date:** [January 28, 2026, 9:31pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/15 "2026-01-28T21:31:05Z")

</div>

Linked servers are always slow. I think you can establish direct access which would be faster, but you have to have a stable ip for the cloud team to whitelist.

---

<div class="post-metadata">

**Author:** ![kananga](https://www.epiusers.help/user_avatar/www.epiusers.help/kananga/32/80812_2.png) [@kananga](https://www.epiusers.help/u/kananga)\
**Post date:** [January 28, 2026, 9:32pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/16 "2026-01-28T21:32:55Z")

</div>

If you have system catalog read permissions, server resources and their performance would be queryable to identify bottlenecks you might be able to work around. If so this would likely be in the ballpark of a good starting place:

> **[sys.resource\_stats (Azure SQL Database) - SQL Server](https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-resource-stats-azure-sql-database)**
>
> sys.resource\_stats returns CPU usage and storage data for an Azure SQL Database.

---

<div class="post-metadata">

**Author:** ![jbooker](https://www.epiusers.help/user_avatar/www.epiusers.help/jbooker/32/83580_2.png) [@jbooker](https://www.epiusers.help/u/jbooker)\
**Post date:** [January 29, 2026, 12:11am UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/17 "2026-01-29T00:11:25Z")

</div>

Perhaps another option for your redesign would be to let Epicor tell your app when data changes via CDC which is free.

> [@Understanding CDC (Full Architecture and Detail Breakdown)](https://www.epiusers.help/t/understanding-cdc-full-architecture-and-detail-breakdown/108164/5):
>
> OK so the 5 minute internals of CDC Post CDC - Change Data Capture is real CDC just not sql servers. it was added in the original 10.0 release because we knew we would need it but at that time Microsoft’s CDC was only available to Enterprise level customers and we didn’t feel that was reasonable for our customers. it was initially only used for ESE - Epicor Social Enteprise. When that was deprecrated in favor of the new Collaborate product the CDC Tables got an actual UI in 10.2.500 and then i…

Perhaps if your cdc push told your webhook the info needed to determine the time sensitivity of the change, it’d be okay not to poll every 5 sec.

For example, if the change info says it’s not needed for immediate queue you’re good to request that change detail in minutes not seconds. 🤷‍♂️

---

<div class="post-metadata">

**Author:** ![bderuvo](https://www.epiusers.help/user_avatar/www.epiusers.help/bderuvo/32/55706_2.png) [@bderuvo](https://www.epiusers.help/u/bderuvo)\
**Post date:** [January 29, 2026, 1:15pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/18 "2026-01-29T13:15:31Z")

</div>

We’re using the read only database as well. like @aosemwengie1 said we havent seen any sync issues and I understand it is real time and not scheduled sync.  
It is designed for reporting, works great for that. As far as responsiveness I haven’t tested beyond our needs. Happy to test for you.  
The connection is limited to ODBC.

---

<div class="post-metadata">

**Author:** ![JMPCONJ](https://www.epiusers.help/user_avatar/www.epiusers.help/jmpconj/32/76359_2.png) [@JMPCONJ](https://www.epiusers.help/u/JMPCONJ)\
**Post date:** [January 29, 2026, 2:04pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/19 "2026-01-29T14:04:47Z")

</div>

> [@bderuvo](#):
>
> It is designed for reporting, works great for that. As far as responsiveness I haven’t tested beyond our needs. Happy to test for you.  
> The connection is limited to ODBC.

We’re using Access/ODBC for a lot of our reporting…stop laughing, it usually works. Response time on pulling data directly from Kinetic tables is pretty good. Performance hits seem to come in on more complex queries especially if they involve local tables. Workarounds have been to create local temp subsets of Kinetic data and then reconnecting.

---

<div class="post-metadata">

**Author:** ![Evan\_Purdy](https://www.epiusers.help/user_avatar/www.epiusers.help/evan_purdy/32/69101_2.png) [@Evan\_Purdy](https://www.epiusers.help/u/Evan_Purdy)\
**Post date:** [January 29, 2026, 2:40pm UTC](https://www.epiusers.help/t/cloud-direct-sql-access/132332/20 "2026-01-29T14:40:27Z")

</div>

Like as a replacement for SSRS?

[Next page](https://www.epiusers.help/t/cloud-direct-sql-access/132332.md?page=2)