A multi-tenant OpenEdge database is a shared database with a shared schema, and logically and physically isolated data storage on a per tenant or group basis. Each object—table, index, or large object (LOB)—is stored in a partition. Partitions keep data physically separate for each tenant. Partitions may exist in the same or in different storage areas. All multi-tenant objects are required to reside in a Type II storage area. Access to a partition can be disabled without deleting the data.

With non-multi-tenant databases, you typically work with users only. With multi-tenant databases, however, you also need to work with other objects, such as tenants, domains, and tenant groups. These objects are meant to ensure that tenant-specific data is delivered to the right tenant user.

Although there are many aspects of multi-tenancy, by implementing tenant support in the database layer, after the tenant identity is asserted, the application code that tenants run when using a multi-tenant database is exactly the same as application code running in a non-tenant configuration. For application users (tenants), after access to the database is authenticated, multi-tenancy is transparent. For application developers, there are very few changes that need to be made to existing applications to support a multi-tenant database. The changes are primarily confined to the areas of security, authorizing users (signing into the application), and database connections. Some applications may have intermingled these types of tasks (security and database connections) into their business logic; however, for most applications, user authentication and security are handled as an independent step when a user initially signs into the application, and the other aspects of an existing application will not need any changes.

OpenEdge multi-tenancy includes the following features:
  • All tenants share the same database schema definitions.
  • Multi-tenant tables store tenant data securely and separately.
  • Tenants must be authenticated for data access.
  • No tenant-based customization for data access operations is required:
    • All tenants use the same queries to access data; the returned results are different based on the individual tenant’s identity.
    • A tenant cannot access another tenant’s data at all.
    • The tenant is unaware of all the other tenants; it accesses the application as though it were an isolated instance, designed just for itself.
  • Tenants can be quickly and easily added, modified, removed, and managed.
  • Shared data can be accessed by all tenants.
  • Deleted tables and sequences for a tenant or tenant group can be recovered while the database is online.
  • Indexes of tables for a tenant or a tenant group can be rebuilt while the database is online.
  • Database utilities and tools are tenant-aware.

There are many advantages to implementing a multi-tenant application environment. A multi-tenant application can provide savings by reducing development and deployment costs to companies that develop applications. These savings can be passed on to customers, increasing competitive advantages for all parties involved.

Savings created by multi-tenancy come from sharing the same resources with multiple tenants. Sharing resources provides a way for an application vendor to create and maintain resources once for all customers, which can result in significant savings.

For example, one benefit a multi-tenant database provides is that the database schema is shared. One copy of the schema is available to all tenants. Schema changes only need to be made once for all tenants. This allows changes to be rolled out faster. Another benefit of the shared schema is that it allows one version of the r-code to be shared by all tenants. Through centralizing resources, all customers are maintained at the same version, reducing the overhead an application provider would otherwise encounter when maintaining multiple versions of an application across deployments.