Using Microsoft Fabric as Database Backend for FastAPI Microservices

[ander7277]

Hi,

I'm building a suite of microservices, starting with a notifications service, and I need advice on database choices for cloud migration.

Current Setup:

- Framework: FastAPI

- ORM: SQLAlchemy

- Migrations: Alembic

- Database: SQL Server (on-premise)

Requirements:

- CRUD operations for notifications

- Database migrations support

- Future expansion to multiple microservices

- Planning to move from on-premise to cloud

Questions:

1. Is Microsoft Fabric suitable for this type of application?

2. Are there any limitations using SQLAlchemy and Alembic with Fabric?

3. What's the recommended approach for microservices data architecture in Fabric?

4. Should I use a SQL hosted in Azure instead? 

Thanks for your help!

[v-echaithra]

Hi @ander7277 ,

May I ask if you have resolved this issue? Please let us know if you have any further issues, we are happy to help.

Thank you.

[v-echaithra]

Hi @ander7277 ,

I hope the information provided is helpful.I wanted to check whether you were able to resolve the issue with the provided solutions.Please let us know if you need any further assistance.

Thank you.

[v-echaithra · Accepted solution]

Hi @ander7277 ,

Thank you @BhaveshPatel , @KevinChant , @harianil  for your inputs.
Microsoft Fabric is primarily a data analytics platform, not a general purpose transactional DB platform. It can host SQL endpoints  and exposes TDS/ODBC/JDBC endpoints, but Fabric is optimized for analytical and lakehouse or warehouse workloads rather than high volume OLTP microservices. For transactional microservices notifications, CRUD-heavy, low-latency writes use a managed relational service built for OLTP Azure SQL Database or Azure SQL Managed Instance. So SQLAlchemy + Alembic can handle your CRUD, migrations, connection pooling, and transactional guarantees then asynchronously replicate or stream data from those operational stores into Microsoft Fabric. They provide full T-SQL surface, ACID, high concurrency, predictable latency, and native support for connection pooling, migrations, backups, and security.

Use Microsoft Fabric for analytics/aggregation stream service data into Fabric for reporting, analytics, ML, and Power BI. This separates OLTP from analytics and uses each platform for its strengths.
If you are using Fabric as primary DB accept limitations, run thorough tests for concurrency/latency, and plan a migration path off Fabric if requirements grow. Consider per-service databases and keep schemas lightweight.

Yes, use Azure SQL or managed instance for microservices that need reliable OLTP behavior. Use Fabric as the analytics backend where you offload reporting/ML. This hybrid pattern gives best operational experience and developer tool compatibility.

Thank you for your patience and look forward to hearing from you.

Best Regards,
Chaithra E.

[BhaveshPatel]

Hi @ander7277 

You can use Dataflow Gen2 for microservice architecture. Dataflow Gen 2 have Fabric SQL which is compatible with Azure SQL and more powerful than Azure SQL.  Basically, Fabric SQL is serverless cloud SaaS database option you can utilize that. Meanwhile, You can use Notebooks option in Delta Lake as well.

Python -- > Apache Spark ( Data Lake ) --> Delta Lake

[KevinChant]

One key point to remember here is that SQL database in Fabric is still in Preview. Maybe select another option to begin with and then review that choice at a later date.

[harianil]

Based on my experience, For workloads like your FastAPI microservices, Fabric might not be suitable. For operational data, use an Azure-hosted OLTP database (Azure SQL Database, Managed Instance, PostgreSQL, etc.) which is fully compatible with SQLAlchemy and Alembic. Later, you can integrate Fabric to handle analytics and reporting from those operational stores