Fabric can use PostgreSQL as a Logical Unit's storage layer, where each business entity's instance is saved in separate rows in PostgreSQL.
This functionality should be used when the main use case is driven mostly from cross-instance queries, for reportings, dashboards or data analytics systems.
This is the preffered option when asking the following:
The Logical Unit's data is saved in PostgreSQL in 2 different schemas:
__{Logical Unit Name}, contains all the Logical Unit table names and data per instance; each table holds:
1.1 __iid + Logical Unit table's original PK as the PostgreSQL table's primary key.
{Logical Unit Name}, contains views on all the Logical Unit tables for Fabric's internal use.
This structure opens the ability to query data in the Business Entity's instance level when needed.
When using the DbLoad Actor in Broadway, it is required to use the batch mode in order to ensure good sync performance results.
The common tables solution is aligned with this functionality, thus the data is saved under {common table schema name} or common, if the schema is set to default.
This mode is supported in the system level; it is not possible to store some of the Logical Units as MicroDB and the others on PostgreSQL.
Data can be encrypted using PostgreSQL encryption at several levels. This encryption provides flexibility in protecting data from disclosure (due to database server theft), unscrupulous administrators and insecure networks. Encryption may also be required to secure sensitive data, such as medical records or financial transactions. For further reading, click here.
In order to turn this functionality on, the following steps should be taken:
For the purpose of getting data of cross-business entities' instances, it is possible to publish data to Elasticsearch by using the Fabric CDC solution.
Business Entity on PostgreSQL is the preferred solution, as it requires to maintain one DB less (no Elasticsearch); however, if scalability is crucial, the Fabric CDC data publishing to Elasticsearch solution should be considered.
Since data is not stored as a MicroDB, the following Fabric capabilities are not supported in this mode:
Fabric can use PostgreSQL as a Logical Unit's storage layer, where each business entity's instance is saved in separate rows in PostgreSQL.
This functionality should be used when the main use case is driven mostly from cross-instance queries, for reportings, dashboards or data analytics systems.
This is the preffered option when asking the following:
The Logical Unit's data is saved in PostgreSQL in 2 different schemas:
__{Logical Unit Name}, contains all the Logical Unit table names and data per instance; each table holds:
1.1 __iid + Logical Unit table's original PK as the PostgreSQL table's primary key.
{Logical Unit Name}, contains views on all the Logical Unit tables for Fabric's internal use.
This structure opens the ability to query data in the Business Entity's instance level when needed.
When using the DbLoad Actor in Broadway, it is required to use the batch mode in order to ensure good sync performance results.
The common tables solution is aligned with this functionality, thus the data is saved under {common table schema name} or common, if the schema is set to default.
This mode is supported in the system level; it is not possible to store some of the Logical Units as MicroDB and the others on PostgreSQL.
Data can be encrypted using PostgreSQL encryption at several levels. This encryption provides flexibility in protecting data from disclosure (due to database server theft), unscrupulous administrators and insecure networks. Encryption may also be required to secure sensitive data, such as medical records or financial transactions. For further reading, click here.
In order to turn this functionality on, the following steps should be taken:
For the purpose of getting data of cross-business entities' instances, it is possible to publish data to Elasticsearch by using the Fabric CDC solution.
Business Entity on PostgreSQL is the preferred solution, as it requires to maintain one DB less (no Elasticsearch); however, if scalability is crucial, the Fabric CDC data publishing to Elasticsearch solution should be considered.
Since data is not stored as a MicroDB, the following Fabric capabilities are not supported in this mode: