Core Data with PostgreSQL physical store instead of SQLite

New to Xcode.


Is there a framework or method to use Core Data to connect to and use PostgreSQL as the physical store via the Persistent Store Coordinator instead of SQLite for developing multi-user client-server applications running on both OS X and iOS?

Answered by NotMyName in 133311022

At the moment, if you want to connect CoreData to PostgresSQL, you have to either find or write your own NSIncrementalStore implementation.


If you're new to XCode, you're probably looking at a fair amount of training to understand NSIncrementalStore's requirements enough to implement the interface, though. But by accounts that I find when looking for "NSIncrementalStore PostgresSQL", it sounds reasonable enough from a technical perspective.

There is nothing like that provided by Apple. Nor, have I encountered any third-party PostgreSQL backed stores.

Accepted Answer

At the moment, if you want to connect CoreData to PostgresSQL, you have to either find or write your own NSIncrementalStore implementation.


If you're new to XCode, you're probably looking at a fair amount of training to understand NSIncrementalStore's requirements enough to implement the interface, though. But by accounts that I find when looking for "NSIncrementalStore PostgresSQL", it sounds reasonable enough from a technical perspective.

Thanks for the response and useful information!


It seems odd to me that Apple included PostgreSQL as the default database server in OS X Server and for some of their own applications, yet they do not provide any connection tools with Xcode or Filemaker for live access (ESS) to PostgreSQL database server.


Curious as to what database is used for the backend to Cloud Kit. Could it be PostgreSQL which is open source?


I want to develop using Xcode, likely with Core Data / Cloud Kit, but need to figure out a way to access years of data already stored in PostreSQL database using these development tools provided by Apple. Any ideas?

To be really honest, if you have "years of data already stored in PostreSQL database" you probably need to stop and think about how you're trying to access the data.


There's a difference in approach and perspective between an object store (what CoreData is really trying to be) and relational database (what SQL databases try to be). It's possible to implement object stores using relational databases, but trying to access relational database using object store tools alternates between 'it works but there's a lot of excess stuff going on' and 'all advantages lost through translation'.


The CoreData persistent store option to use an sqlite database is the "put our object store data into a relational database, using machine generated table names, row names, and schema." It's not "translate an SQL database to the CoreData system".


There are some SQL databases that are going to be trivial to map into a simple entity system. There are other SQL database schemes aren't going to work very well at all. That's why you have to do it yourself.


Well, that and I get the impression that some things get implemented in CoreData because "We figured out how to do this neat thing, let's publish it" and then they start evangelizing to get other people to use it. 🙂

Core Data with PostgreSQL physical store instead of SQLite
 
 
Q