# Coded Apps - Data Fabric vs SQL Server vs Data Fabric + SQL sync?

**URL:** <https://forum.uipath.com/t/coded-apps-data-fabric-vs-sql-server-vs-data-fabric-sql-sync/5776326>\
**Category:** Apps\
**Tags:** question, data-fabric, coded-apps, activities\
**Created:** [September 11, 2026, 4:27pm UTC](https://forum.uipath.com/t/coded-apps-data-fabric-vs-sql-server-vs-data-fabric-sql-sync/5776326 "2026-09-11T16:27:47Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kirbymisa](https://sea2.discourse-cdn.com/uipath/user_avatar/forum.uipath.com/kirbymisa/32/545795_2.png) [@Kirbymisa](https://forum.uipath.com/u/Kirbymisa)\
**Post date:** [September 11, 2026, 4:27pm UTC](https://forum.uipath.com/t/coded-apps-data-fabric-vs-sql-server-vs-data-fabric-sql-sync/5776326/1 "2026-09-11T16:27:48Z")

</div>

**Title: Coded Apps — Data Fabric vs SQL Server vs Data Fabric + SQL sync?**

Hi everyone,

We’re currently exploring UiPath Coded Apps for a new solution and are looking at different options for the backend/data storage. Nothing has been decided yet, so I wanted to get some thoughts from people who have worked with these approaches.

So far, we’re considering:

**Option 1 - Data Fabric only**  
Coded App → Data Fabric

**Option 2 - SQL Server as the backend**  
Coded App → secured REST API → SQL Server

**Option 3 - SQL Server + Data Fabric synchronization**  
Coded App → Data Fabric ↔ UiPath Process ↔ SQL Server

For Option 3, the idea would be to have the data stored in SQL Server and use a UiPath process to synchronize the relevant data between SQL and Data Fabric so the Coded App can work with the Data Fabric entities.

I’m mainly looking to get some thoughts on the pros/cons of these approaches and what others have seen work well.

For example:

- Has anyone used a Coded App with SQL Server through a REST API?
- Is the SQL + API approach practical and secure for a production application?
- Has anyone used a SQL ↔ Data Fabric synchronization approach? How did that work out?
- Does the synchronization approach add too much maintenance/complexity, or are there good reasons to have both?
- If you’re starting a new Coded App solution, what would make you choose Data Fabric vs SQL vs a combination of both?

Just looking for ideas and experiences from anyone who’s worked with these architectures.

Thanks!

---

<div class="post-metadata">

**Author:** ![Ashish\_Rao](https://sea2.discourse-cdn.com/uipath/user_avatar/forum.uipath.com/ashish_rao/32/508131_2.png) [@Ashish\_Rao](https://forum.uipath.com/u/Ashish_Rao)\
**Post date:** [September 13, 2026, 12:52pm UTC](https://forum.uipath.com/t/coded-apps-data-fabric-vs-sql-server-vs-data-fabric-sql-sync/5776326/2 "2026-09-13T12:52:50Z")

</div>

Hi @Kirbymisa, it is good start exploring coded apps the way you are doing.  
Coming to your query for using SQL server with APIs, this would works as expected while you are developing and testing on your system. But you won’t be able to productionize it. The SQL server needs to get connected to Data Fabric via Integration Services.  
I would rather choose working with data fabric to have better control and smooth integration.

---

<div class="post-metadata">

**Author:** ![Ehab\_Sawars](https://sea2.discourse-cdn.com/uipath/user_avatar/forum.uipath.com/ehab_sawars/32/401516_2.png) [@Ehab\_Sawars](https://forum.uipath.com/u/Ehab_Sawars)\
**Post date:** [November 1, 2026, 3:14am UTC](https://forum.uipath.com/t/coded-apps-data-fabric-vs-sql-server-vs-data-fabric-sql-sync/5776326/3 "2026-11-01T03:14:21Z")

</div>

A secured API backed by SQL isn’t inherently limited to development. The important boundary is that Coded Apps host browser code: authentication checks, database credentials and SQL access must stay in a backend service, not the JavaScript bundle.

If SQL is already the system of record, I’d start with option 2. Choose Data Fabric alone when its model and integration fit the application. I’d add synchronization only for a specific need, with one authoritative writer and explicit conflict/deletion handling; otherwise option 3 adds two places for data to disagree.