Deep Populate revolutionizes how developers handle complex relational data by fetching nested information from multiple databases with a single API call. No more writing intricate JOIN queries or managing multiple database connections manually.
Traditional database queries require developers to write complex JOIN statements or make multiple API calls to gather related data. Deep Populate eliminates this complexity by automatically creating a network of relationships across multiple database systems, returning comprehensive nested data structures in one request.
Before Deep Populate:
-- Multiple queries needed
SELECT * FROM persons WHERE name = 'Kishan';
SELECT * FROM streets WHERE id = person.street_id;
SELECT * FROM areas WHERE id = street.area_id;
-- ... and so on for 8+ more queries
With Deep Populate:
// For Schema defined Deep populate
/api/schema/user-path/instance/database/table?deep=[{s_key:"state_id"}]
OR
// To custom Deep populate or override the default schema relation
/api/schema/user-path/instance/database/table?deep=[{s_key:"state_id",t_instance:"oracle",t_db:"inventory",t_col:"states",t_key:"id"}]
The notorious N+1 query problem disappears when you can fetch all related data in one optimized request. Deep Populate handles the complex query optimization behind the scenes, dramatically reducing database load and improving application performance.
Where traditional ORMs struggle with multi-database or cross-database resource retrieval, API Maker can over come that limitation with the support of 8 database including both SQL and No-SQL databases including MongnoDB, PostgreSQL, MySQL many other which you can check here.
Built-in query optimization ensures that even complex multi-level relationships execute efficiently. The system intelligently batches queries, uses appropriate indexes, and implements caching strategies to maintain fast response times.
Database relations are defined at the time of schema creation, When the user targets a specific field via a request, API Maker travels to the database, retrieves the data and wraps the content into a single json response object. This allows API Maker to build relations between different database instances without any limitation.
Let's say if the user does not want to define a schema and wants dynamic cross-database data retrieval or wants to override the default relation, the s_key and t_key properties in the deep-populate parameter object are used in this scenario. To learn more about this feature, click here.
Example Relationship Chain:
Person → Street → City → Country
Each arrow represents a foreign key relationship that Deep Populate resolves automatically, even when the data spans different database systems.
Sample Request Object With Deep Populated Data:
Deep Populate requests use a nested JSON structure that mirrors your data relationships:
{
"find": { "person_name": "John" },
"deep": [
{
"s_key": "street_id",
"t_key": "id",
"t_table": "streets",
"deep": [
{
"s_key": "city_id",
"t_key": "id",
"t_table": "cities",
"deep": [
{
"s_key": "country_id",
"t_key": "id",
"t_table": "countries"
}
]
}
]
}
]
}
This structure tells API Maker exactly how to traverse your data relationships, regardless of which databases contain each piece of information.
Sample Response Object With Deep Populated Data:
{
"person_name": "John",
"streets": {
"id": 5,
"name": "Main Street",
"cities": {
"id": 101,
"name": "New York",
"countries": {
"id": 1,
"name": "USA"
}
}
}
}
When dealing with large result sets, The stream APIs can be used to optimize the api response content, The streams can help by providing the content of the request into chunks without loading the data into memory which will prevent memory overload in larger data infrastructures.
Benefits Of Using Deep Populate With Streams:
The built-in caching system recognizes patterns in Deep Populate requests and automatically caches frequently accessed data combinations. This intelligent caching reduces database load and improves response times for common query patterns.
Caching Features:
Frequently used Database relationships can be defined into api maker schemas which allow user to request the Data by providing the name of the field in the request which makes cross-database data retrieval faster and easier. Visit this page for more detail.
// Simplified request with pre-configured relationships via database schema
{
"find": { "person_name": "Kishan" },
"deep": ["full_address_chain"]
}
Deep Populate works seamlessly with standard REST API patterns, extending traditional GET requests with powerful relationship traversal capabilities. Your existing API clients require no modifications to benefit from Deep Populate functionality.
While maintaining REST simplicity, Deep Populate provides GraphQL-like flexibility for specifying exactly which related data you need. This approach combines the best aspects of both API techniques without requiring a complete architectural change.
In microservices environments, Deep Populate can aggregate data from services that manage different databases, providing a unified data access layer that simplifies client application development.
API Maker provides comprehensive testing tools for Deep Populate queries, including query visualization, performance profiling, and relationship validation. These tools help developers understand query execution paths and optimize data access patterns.
While migrating from other existing systems, People often encounter the problem of defining the relations in the database which can be quite painful, In API Maker the Database relations can be created with one click and the user can start using features like Deep Populate without any extra hustle.
The feature works seamlessly across API Maker's supported database ecosystem, Database relations between SQL to SQL are possible as well as SQL to NoSQL:
Relational Databases:
Document and Distributed Databases:
Feature Related To Getting Data | API Maker | Supabase | Firebase | Appwrite |
---|---|---|---|---|
Cross-Database Queries | ✅ Native support across 8+ databases | ❌ Single PostgreSQL only | ❌ Single Firestore only | ❌ Single database per project |
Real-time Multi-DB Relations | ✅ Live updates across databases | ⚠️ PostgreSQL only | ⚠️ Firestore only | ⚠️ Single database |
SQL + NoSQL Integration | ✅ Seamless MySQL→MongoDB queries | ❌ PostgreSQL only | ❌ NoSQL only | ⚠️ Limited SQL support |
Unlimited Nesting Depth | ✅ Person→Street→City→Country→... | ⚠️ Manual JOIN complexity | ❌ Limited subcollection depth | ⚠️ Manual relationship handling |
Auto Query Optimization | ✅ Built-in batching & caching | ⚠️ Manual optimization needed | ⚠️ Limited optimization tools | ⚠️ Basic optimization |
Schema-less Dynamic Queries | ✅ Override relations on-the-fly | ❌ Fixed schema required | ❌ Collection structure fixed | ❌ Schema-dependent |
Multi-Database Transactions | ✅ Cross-database types ACID support | ❌ Single database only | ❌ Limited transaction scope | ❌ Single database only |
Enterprise Database Support | ✅ Oracle, SQL Server, MySQL, etc. | ❌ PostgreSQL only | ❌ Firestore only | ⚠️ Limited enterprise options |
Supabase excels at PostgreSQL management but struggles with multi-database scenarios.
Firebase's Firestore is excellent for rapid prototyping but hits walls with complex data.
Many developers ask why API Maker doesn't offer GraphQL support. The answer is simple: Deep Populate provides all the benefits of GraphQL without any of the complexity, overhead, or limitations.
GraphQL was created to solve the problems of over-fetching data and making multiple API calls. Deep Populate solves these same problems with better performance and without having to learn unnecessary material about how to retrieve data from a table.
GraphQL emerged to address several key issues with traditional REST APIs:
Deep Populate solves all these problems better than GraphQL.
Ready to transform your data access layer? Explore API Maker's Deep Populate documentation see how it can simplify your next project.
Deep Populate supports unlimited nesting levels. You can traverse relationships from Person → Street → Area → City → State → Country → Continent → Planet → Galaxy and beyond. However, for optimal performance, we recommend keeping queries under 10 levels deep.
Schema-based requests use pre-defined relationships (deep: ["full_address_chain"]) for simplicity and performance. Custom requests let you specify exact relationships on-the-fly with full control over source and target databases. Use schemas for common patterns and custom for one-off queries.
Absolutely. Deep Populate works with API Maker's real-time features. You can set up webhooks that trigger when any data in your relationship chain changes, and use streaming APIs to get live updates of nested data structures.
Yes. You can apply filters, sorting, and pagination at any level of your deep populate query. For example, you can get a person's address while only including cities with population > 100,000, sorted by name.
API Maker handles database failures gracefully. If a database is unavailable, the query returns partial results up to the point of failure, along with error details. You can configure fallback behavior and retry logic for critical data paths.
Deep Populate includes automatic query optimization, intelligent batching, and built-in caching. For very large datasets, you can use streaming APIs to process results in chunks without loading everything into memory.
Yes, absolutely. Deep Populate seamlessly connects data across all supported databases - MySQL, PostgreSQL, MongoDB, Oracle, SQL Server, MariaDB, TiDB, and Percona XtraDB. You can start with a MongoDB document and traverse to PostgreSQL tables without any additional configuration.
Learn more about API Maker's low-code backend platform and other powerful features at apimaker.dev
{
"find": {
"person_name": "Kishan"
},
"deep": [
{
"s_key": "street_id",
"t_key": "id",
"t_table": "streets",
"deep": [
{
"s_key": "area_id",
"t_key": "id",
"t_table": "areas",
"deep": [
{
"s_key": "city_id",
"t_key": "id",
"t_table": "cities",
"deep": [
{
"s_key": "state_id",
"t_key": "id",
"t_table": "states",
"deep": [
{
"s_key": "country_id",
"t_key": "id",
"t_table": "countries",
"deep": [
{
"s_key": "continent_id",
"t_key": "id",
"t_table": "continents",
"deep": [
{
"s_key": "planet_id",
"t_key": "id",
"t_table": "planets",
"deep": [
{
"s_key": "galexy_id",
"t_key": "id",
"t_table": "galaxies"
}
]
}
]
}
]
}
]
}
]
}
]
}
]
}
]
}
{
"person_name": "Kishan",
"street_id": { // from MongoDB
"id": 12,
"street_name": "TIRUPATI",
"area_id": { // from MySQL
"id": 24,
"area_name": "RANIP",
"city_id": { // from SQL_SERVER
"id": 382480,
"city_name": "AHMEDABAD",
"state_id": { // from MariaDB
"id": 91,
"state_name": "GUJARAT",
"country_id": { // from Oracle
"id": 4,
"country_name": "INDIA",
"continent_id": { // from PostgreSQL
"id": 3,
"countinent_name": "ASIA"
"planet_id": { // from Ti DB
"id": 2,
"planet_name": "EARTH"
"galexy_id": { // from Percona XtraDB
"id": 1,
"galaxies_name": "Milky Way"
}
}
}
}
}
}
}
}
}