How Floating Licences Work for a Database Team
The Definition of a Floating Software License
A floating software license, also known as a concurrent license, grants an organization a set number of seats that any user in that organization can claim: the software can be installed on far more machines than there are seats, as long as simultaneous use stays inside the purchased count[1]. Rather than binding an individual license key to a specific developer or a single physical workstation, the floating model decouples software installation from software execution.
Any number of team members can install the application across their local workstations. The total number of users who can run the application at the exact same moment is governed by the concurrent seat limit purchased for the pool[2]. When a developer launches the tool, the application requests an active seat token. When the developer quits the application, that token returns to the shared pool immediately.
Fixed allocation models assign an individual software seat to a single employee permanently. In contrast, floating licensing aligns seat capacity with actual concurrent utilization instead of total headcount. This structure eliminates paid seats that sit idle on secondary machines or across off-shift hours.
- Centralized pool management: software tokens are allocated dynamically from a central inventory rather than tied to local hardware IDs.
- Unlimited installations: engineers install the client application on desktop, laptop, and lab environments without purchasing separate seat keys.
- Concurrency enforcement: the licensing engine blocks launches only when active sessions reach the purchased concurrent seat ceiling.
Mechanics of Floating License Access and Servers
License checkout mechanics follow a client-server validation handshake whenever a user initiates an application session. When a user launches the application, their machine requests a license from a central server; if one is available the server checks out a token to that user, and when the user closes the application the token returns to the pool for someone else[3]. The server verifies available pool capacity, logs the checkout event, and grants a time-bounded lease to the client.
When the user finishes working and exits the software, the client notifies the server to release the token immediately. If a network disruption occurs or an application crashes, the server automatically reclaims the abandoned token once the heartbeat lease expires, returning the seat to the shared inventory.
Deployment Options for Floating License Servers
Engineering teams deploy license management infrastructure through two primary architectures:
- Vendor-hosted licensing services: the vendor runs the license verification endpoint, and the team manages who may draw from the pool through a web account rather than through internal server hardware.
- Self-hosted on-premises servers: organizations deploy license server daemons inside their private network using Docker containers, virtual machines, or local CLI services. This approach satisfies strict security requirements in air-gapped environments where developer machines cannot reach external cloud endpoints.
DbSchema offers both routes. On the account-based route there is no server to install or maintain: the licence owner adds the allowed users' email addresses in the Customer Area, each engineer signs in from Help then Register License then DbSchema Account with their own address, and DbSchema leases a seat from the licensing service for that session. The list of allowed users can be as long as you like, because the purchased quantity caps only how many of those people can work at the same time. For networks with no direct internet access, DbSchema ships a self-hosted Floating License Server that runs either from the official Docker image or from DbSchemaCLI, which is part of the standard installation: load the floating licence key with register -f, start the server with license server -s, then point each client at the server host and port, or set DBSCHEMA_FLS_HOST and DBSCHEMA_FLS_PORT on the client machines so the server is found without any manual configuration[6].
A seat is released when the engineer closes DbSchema or unregisters from Help then Unregister, and the seat of a crashed or disconnected client is freed automatically once it stops contacting the server. A running application keeps its seat: DbSchema applies no inactivity timeout[6].
Three Common Types of Software Licensing
Software licensing models in engineering departments fall into three standard categories: floating, named-user, and node-locked. Each model carries distinct trade-offs for mobility, cost, and administrative overhead.
| Licensing Model | Binding Mechanism | Machines Per Seat | Offline Support | Primary Advantage |
|---|---|---|---|---|
| Floating (Concurrent) | Central license server pool | Unlimited installs, 1 active session per token | Only while a token lease is held | Maximizes seat utilization across rotating shifts and intermittent users |
| Named-User | Individual user identity or email | Any machine, but 1 named person per seat | Requires periodic online identity refresh | Simplifies user-level accountability and audit tracking |
| Node-Locked | Fixed hardware identifier (MAC/UUID) | 1 designated machine | Operates completely offline without network checks | Prevents multi-machine credential sharing in dedicated lab environments |
Database architecture and schema design tools frequently benefit from floating licensing because database modeling is rarely an eight-hour continuous task for every software engineer. Developers design tables during sprint planning, review schema diffs before deployment, and explore query execution plans periodically. A floating license pool lets an entire team of forty developers share twelve active database design tool seats without workflow interruptions.
Decision Criteria for Engineering Managers
Engineering managers must evaluate team work patterns before committing to a licensing architecture. Purchasing dedicated named licenses for an entire engineering organization creates substantial budget waste when tooling usage is intermittent.
Evaluate four operational criteria to determine whether a floating model fits your team:
- Usage intermittency: assess how many hours per week individual engineers spend in the tool. If developers perform visual modeling, schema comparison, or migration reviews sporadically, a shared concurrent pool delivers higher ROI than dedicated seats.
- Multi-timezone distribution: determine whether your engineering teams operate across distributed geographic regions. Teams in Europe, the Americas, and Asia-Pacific can utilize the exact same floating license pool sequentially across consecutive working days.
- Onboarding and offboarding overhead: measure the administrative effort required to provision and revoke software licenses. Floating licenses eliminate the need for IT administrators to reassign seat keys manually whenever contractors or full-time engineers change roles.
- Offline and air-gapped security policies: verify whether team members require access in isolated database networks or off-grid field environments. A self-hosted license server keeps activation inside your own network, so machines that cannot reach a vendor endpoint still get seats.
For specialized roles like dedicated Database Administrators (DBAs) or Lead Data Architects who require continuous, full-day modeling capabilities, named seats remain practical. For general backend engineers, QA testers, and data analysts, floating pools provide flexible access without software seat bloat.
Methods to Test and Monitor License Usage
Capacity planning for concurrent licenses requires empirical usage tracking rather than guesswork. Engineering managers should start by calculating the ratio between total authorized users and active concurrent sessions.
Industry benchmarks show that engineering teams with intermittent workflows operate efficiently at a 3:1 ratio of total developers to concurrent floating seats[4]. A team of sixty developers typically requires a pool of twenty floating seats to maintain uninterrupted productivity.
Key Monitoring Metrics and Optimization Tactics
Track three critical server metrics to right-size your license inventory:
- Peak concurrent usage: record the maximum number of simultaneous checkouts during high-intensity sprint planning or release cycles.
- License denial frequency: log events where a user requests a token but receives a denial because the pool is exhausted. Once denials become a recurring weekly occurrence rather than a rare spike, expand the pool size.
- Average session duration: identify how long tokens remain checked out per developer session.
Check what your vendor actually exposes before you plan around it, because the reclaim behaviour differs sharply between products. DbSchema applies no inactivity timeout: a seat stays checked out for as long as the application is open and returns to the pool only when the engineer closes DbSchema or unregisters, or when a crashed client stops contacting the server. On a self-hosted Floating License Server, license server -l lists the users currently holding a seat and license server -i reports server status[6], which is where a peak-concurrency and denial record comes from. The practical consequence for capacity planning is that applications left open all day count against the pool, so a team habit of closing the tool does more for seat availability than any server setting.
DbSchema Editions and Community Tier Limits
DbSchema is sold in three editions plus a floating license, covering individual developers, collaborative engineering teams, and enterprise data architects, with a 15-day trial of the paid tiers. Understanding what each tier provides helps managers choose the right edition for their database infrastructure.
The Community Edition is a free database tool that allows developers to connect to all supported SQL and NoSQL engines, reverse-engineer schemas into visual diagrams, and write queries in a built-in SQL editor. However, free database tools like the Community Edition omit critical collaboration and deployment capabilities required for production team workflows.
The free Community Edition explicitly omits:
- Saving design models to local project files: Community does not allow saving your database schema into a .dbs project file for Git version control and offline modeling.
- Schema synchronization: Community cannot compare design models against live databases or generate automated DDL migration scripts.
- Interactive documentation export: Community cannot generate searchable, interactive HTML5 documentation with vector diagrams and mouse-over schema comments.
- Visual query builder and relational data browsing: Community lacks visual multi-table query construction and relational data exploration across foreign keys.
- Data generator and data importer: Community does not include automated test data generation or multi-format data import tools.
- Database management applications: Community does not unlock DbSchema's built-in database management utilities, which the edition matrix on the purchase page lists as a Pro-and-above feature.
Pro Edition includes all of these missing capabilities, enabling teams to version schemas in Git, deploy structural changes safely, and document databases automatically. Architect Edition builds on Pro by adding database-independent logical and conceptual modeling along with custom AI API key integration.
One row of the matrix runs the other way. The AI Assistant is sold as its own subscription and the matrix marks it available on every edition, Community included; only the own-key variant, where you supply your own AI provider key, is restricted to Architect.
Three-Year Cost and Perpetual Renewal Terms
Evaluating database tooling costs over a multi-year horizon reveals significant savings when comparing perpetual fallback licenses to recurring subscriptions. The prices below are the published list rates for perpetual seats, optional annual maintenance, and the shared floating pool.
| Edition / License Type | One-Time Perpetual Price | Annual Maintenance Renewal (Optional) | Git & Team Modeling |
|---|---|---|---|
| Community Edition | Free | None | No (offline file save omitted) |
| Pro Edition | $294.00 + taxes | $75.00/year after the free first year | Yes (full .dbs file and Git support) |
| Architect Edition | $470.40 + taxes | $120.00/year after the free first year | Yes (logical, conceptual and physical) |
| Floating License (Architect tier, per concurrent seat) | $1,168.00 + taxes | $280.00/year after the free first year | Yes, shared across the team up to the purchased concurrency |
The floating pool is sold only on the commercial perpetual plan, and the purchase page labels its card Architect, so the pool carries the Architect feature set rather than the Pro one. It is priced per concurrent seat and the quantity is chosen at checkout, where the vendor's store applies a volume discount of 10% from five seats and 20% from ten.
On the perpetual plan, maintenance and upgrades are free for the first year, and the Floating License is listed as including 1 year of updates before the optional $280.00 per year renewal applies[5]. After that first year, the purchased license remains fully operational, so teams can continue using their installed version indefinitely with zero mandatory fees.
Organizations that want continuous access to new feature releases can renew maintenance at the published annual rate for their edition once the free first year ends[5]; DbSchema's licensing page describes that renewal as what keeps you eligible for the latest features and security fixes and keeps technical support open. Over a three-year horizon, one perpetual Pro seat therefore costs the one-time purchase plus two optional renewal years, and the software keeps running even if you stop renewing. A floating pool is bought per concurrent seat rather than per person, so the number to compare is how many engineers need the tool at the same moment against how many need it at all: one concurrent seat costs roughly two and a half named Architect licences, which means the pool starts to pay for itself at about three sharers per seat, close to the 3:1 ratio above.
Frequently asked questions
What is a floating license in software?
A floating license, or concurrent license, is a model where a limited number of seats are shared across a larger team. Anyone can access the tool, but the total number of simultaneous users cannot exceed the purchased quantity.
How does a floating license server work?
When a user opens the software, the application requests a token from a central server or cloud account. Once the user closes the application, the token is released back to the pool for another team member to claim.
What is the difference between named and concurrent licenses?
A named license is locked permanently to a specific individual and cannot be shared. A concurrent license allows flexible access on a first-come, first-served basis, making it ideal for teams with shift workers or intermittent software needs.
How do you calculate the right number of concurrent users?
Engineering managers analyze peak usage times and shift patterns. A common baseline is a 3:1 user ratio, meaning one purchased seat supports three intermittent users without causing severe access denials.
What features are missing from DbSchema Community Edition?
The free Community tier lacks team collaboration features like saving the design model to a Git-tracked file, schema synchronization, the visual query builder, relational data exploration, and interactive HTML5 documentation export.
How does a perpetual fallback license work?
A perpetual license requires a one-time payment that grants lifetime access to that specific software version. It includes one year of updates; subsequent updates require an optional renewal fee, but the base software never expires.
Get Started for Free
To pressure-test any of this on your own stack, download DbSchema and open a visual design model directly against your live database. The 15-day trial of the paid editions covers schema synchronization, interactive HTML5 documentation, and version-controlled Git workflows across your engineering team.
Sources
Try DbSchema against your own database
Reverse-engineer your schema into an interactive ER diagram and keep the model in a .dbs file that versions cleanly in Git. Community Edition is free; Pro and Architect are sold as a one-time licence, and a floating pool shares concurrent seats across the team.
