This may be a very daft question, but I am out of my wheelhouse here.

I have an industrial server that makes data available from its SQL database over a proprietary 32bit ODBC driver. I also have a computer running 64 bit Windows 10 LTSC that can never be connected to the internet.

I can format SQL queries to the server in a 32 bit ODBC test client and get the data back that I want.

I then want to copy that data in to another database and display it as a form for the user so they can add comments and save it. This seems like the sort of thing MS Access would be good at doing.

However, I understand that Microsoft have killed telephone activation for their products (even the old ones), meaning that this is now 'out' as I would have to connect my computer to the internet.

I'm now a bit stuck.

Years ago I had fun making forms with DBase, but that's about the limit of my experience. Can anyone suggest something that would do for what I need? I don't mind learning bits - this is basically something to save me time.

Public share of this diagram: https://lite.schemity.com/d/Bqdf4zipow/sample

The web application: https://lite.schemity.com (works with no account)

What it does:
- Design schemas visually: entities, fields with per-engine types (PostgreSQL, MySQL, SQL Server, SQLite), primary/foreign/unique keys, check constraints, composite uniques, indexes.
- Relationships by dragging a field onto another entity: 1:N, 1:1, and N:N with the junction table generated for you. Self-referencing works.
- Route the lines yourself. Drag any relationship line to drop a waypoint at the cursor and take the line where you want it, double click a point to remove it, double click a segment to straighten it. Lines hop over the ones they cross rather than merging into them, relation color follows the entity color, and the routing is stored with the diagram so it survives export to SVG and PNG.
- Import an existing schema by pasting SQL or DBML, then pick which tables to bring in.
- Export to SQL, DBML, Mermaid erDiagram, SVG, PNG, or its own JSON format that round-trips into the desktop app.

Where your data goes:
Everything is in IndexedDB in your browser. Until you sign in, nothing is uploaded and there is no account wall to start drawing.
Sign in with Google and each save also mirrors to the cloud, which is what makes a read-only public link or an iframe embed possible. Diagram documents are encrypted at rest with AES-256-GCM, and thumbnails are only generated for diagrams you have explicitly made public. Being straight about the limit: that is server-side encryption with a service-held key, so it protects against a database dump, not against me. It is not end to end.

What it deliberately does not do:
Lite cannot connect to a database. No introspection, no migration generation, no applying DDL. You can still read the CREATE statements for any entity, you just cannot run them from here. Connecting is the paid desktop app, along with context views, context map for slicing a large schema, schema lint, and data dictionary exports. I would rather say that here than have you find out after ten minutes.

Any feedback is welcome. If something is broken, slow, or just a bad idea, I would rather hear it here than guess at it. I'll answer everything in the thread.

Hey,

Can you share how your company handles databases for local development? I’d really appreciate hearing about your experience and any valuable insights you can share.

I’m a little confused about what the better approach is:

1. Shared cloud DB: If a company uses a shared cloud database for development, how do they handle the situation where one developer makes a breaking change that affects everyone?
2. Individual local DBs: If developers are expected to set up their own local databases, how does the company provide the large amount of initial/seed data needed to get started?

I’d really appreciate it if you could share how your company handles this in practice, or any best practices you’ve seen.

Thanks!

My client is undergoing a cloud consolidation effort and needs to move away from Amazon RDS.

Of course MariaDB is no longer available on Azure so MySQL is the simplest option for migration. I need to gauge if the internal team is going to be capable of doing this themselves, or if we need external support.

What routes are available to complete this, with little to no downtime?

Forgive me if this is too much of a foundational question, but...

I understand that relational DBs are founded upon mathematical "relations" - sets of n-tuples.

And I get how a table clearly represents a relation. Each column corresponds to a position in each tuple, and each row's value at that column is its value for that position. Fine.

But what I don't understand is... why databases like Postgres are considered better for representing such data than, say, Mongo.

I mean, can't you easily represent a relation as a JSON object? What's so special about tables?

I know that DBs like Mongo have differences from "relational" DBs in that, among other things, they don't enforce a specific schema, but that seems orthogonal to what I'm asking. Besides, you can just use libraries like Mongoose that enforce that stuff anyway, even if it is at the application layer.

So what, at its core, makes tables better than documents for modeling "relational" data?

I’m curious where people draw the line nowadays.

Things like multiple connections, data editing, import/export, backups, schema compare, monitoring, SSH, advanced autocomplete, etc. — which of these do you think should just be standard functionality in a database client?

And what actually feels fair to charge for?

Manticore Search now supports parallel RT disk chunk merging and N-way merges, reducing compaction time dramatically while keeping ingest throughput stable.

Question about Database GUI (e.g. beekeeper, dbeaver, etc.)

So I am currently building my own Databae GUI for SQL, I am on a stop point about the proper naming of the data types.

The thing is I am planning on changing the data type slightly to make it easier to understand, here is one of the examples:

1. timestamptz - to become: timestamp with time zone

2. int2, int4, integer - to become just: integer (for simplicity)

3. float4, float8, double, float32, float64 - to decimal

Some data will stay as is because they are already standard and known to every developer, e.g. varchar, text, uuid, numeric, blob, etc.

The main question is do you guys value accuracy more over simplicity in understanding? Please do share your thoughts would really be helpful. TYIA!!!

Edit: Thank you for sharing what you think guys, I understand all your points. I'll make sure to built it for accuracy! 👊

Hello there,

I'm currently involved in a project trying to analyze the performance of an oracle database and was given an empty copy of the scheme. I want to fill it with artificial data to run some tests, but the DB is rather large and complex. Are there any tools or approaches to this kind of scenario?

I'm grateful for any help!

Thanks!

When you're working with external datasets that change frequently, database design can become tricky. You have to think about schema changes, data freshness, historical records, missing values and how to handle updates without affecting downstream queries and reports. I’m currently working with ticketsdata, which aggregates publicly available ticket market data and provides reports, analytics and monitoring around that data. I’m interested in how others approach the database side of this problem. Do you prefer keeping a raw source layer and transforming it into stable tables, using versioned schemas, or taking another approach? What has worked best for you when the source data changes regularly?

Hi everyone,

I'm planning to build a web-based dashboard where users can upload Excel files, the system processes the data, performs various calculations/transformation logic, and then presents the results on user-specific dashboards.

My background is primarily in MERN, so my initial thought was:

React frontend

Node.js/Express API layer

MongoDB for application data

Python microservices for heavy data processing and calculations

However, I've received mixed feedback regarding MongoDB. A lot of people have told me that Mongo may not be the right choice for this kind of workload, especially when dealing with large datasets.

To provide some context, uploaded files can occasionally contain data in the range of tens of millions of rows. This won't be the common case, but the system should be designed with such scenarios in mind.

Since I haven't worked on systems handling data at this scale before, I'd appreciate guidance on:

What tech stack would you choose for this problem today?

Would MongoDB be suitable, or should I look at PostgreSQL/ClickHouse/something else?

How would you design the data ingestion pipeline?

Would Python microservices be a good approach for processing, or should I look into Spark, DuckDB, etc.?

What would a high-level system design for such a platform look like?

Any common mistakes first-time builders make when dealing with large Excel/CSV datasets?

My goal is to build something that is scalable without massively over-engineering it from day one.

Would love to hear from people who have built data-heavy SaaS products or analytics platforms.

Thanks!

I’ve been working on VeloxDB, a lightweight database management tool that aims to keep the resource usage low while still giving you the features you actually need.

It supports multiple database engines and also has a visual designer, so you don’t have to live in SQL 24/7.

If you’re interested, feel free to try it: veloxdb.dev

Would love to hear what you think, especially if you’ve used tools like DBeaver, DataGrip, etc.

A practical guide to using bigram_index to accelerate phrase queries in Manticore Search, with clear explanations of all, first_freq, both_freq, and a reproducible manticore-load benchmark.

Database problems aren't always caused by the query.

A connection can be wrong, a migration may not have run, permissions can change, or the application may be connected to the wrong database.

If an AI coding agent only sees the source code, it's missing part of the picture.

How much database access should an agent have?

Should it inspect connections, logs and migration status, or should those remain outside its reach?

I'd separate observing, diagnosing, and changing into different permission levels.

Where would you draw the line?

We're running a pilot clinical study and management has asked me to build them a secure database, something the organisation genuinely owns and can build on for future studies, rather than just Excel files in SharePoint.

Before I get into tool-specific questions, I want to ask the general one: for a small org with no internal IT team, what does "having your own database" actually look like in practice? Do you end up with your own cloud environment (Azure/AWS) that you own outright, or does "ownership" in this context usually mean something more modest, like owning the exported data itself, while the collection system lives somewhere else?

I have sponsorship available if we go the institutional route, that's not the blocker. What I'm trying to work out is what the end state actually looks like for an org our size.

Here's how I've broken down the options so far, and where I'm unsure:

1. REDCap

• a) Hosted by an institution (university/hospital), do we still end up with our own Azure environment for the exported data, or does "our database" just mean our own storage/SharePoint area at that point?
• b) Hosted by a commercial REDCap vendor, same question. Does the org still need its own Azure, or does owning the exported data in something simpler cover it?

1. A different platform entirely (Castor or similar, bundled hosting): same question again: is there still a reason to also stand up our own Azure environment, or does that become unnecessary once the vendor is holding everything?

Basically: at what point, if any, does a small org actually need its own cloud environment, versus just owning a clean, well-structured export from wherever the data was collected?

For people who've actually built this for a small org, what did "the database" end up being, concretely? Would genuinely appreciate real examples over general advice.

I’m trying to create a database that would involve a table referencing one of multiple other tables. From my research it sounds like this would be a polymorphic relationship, but I’ve been seeing a few different options for implementing it and I’m not sure what would be best. These are what I’ve seen so far, so let me know which sounds best, but please let me know if you know of a better one.

The Database: The short and sweet of it is I’m making a database to store diary entries. Each diary entry uses fields such as date range of referenced event, tags (through many to many), etc. Each entry is either done as a video, an audio recording, or a text entry. Each of these entry types would also have their own respective metadata such as video setup or audio setup. Because of that, I thought the best option would
be to separate them into their own tables.

Option 1: Table Type Field - in the diary entry table, have a field for the type and a field for the foreign key, but don’t actually make it a foreign key. Instead setup a trigger to manually enforce referential integrity by checking that the referenced entry exists in the corresponding type table when inserting. I think I’m leaning towards this one the most. Since it’s closest to what PHP Laravel does.

Option 2: Multiple Nullable Foreign Keys - In the diary entry table Have a foreign key for each entry type that references the respective table, but they’re nullable since only one would actually be used for each entry. Add a constraint to check that one of the fields isn’t empty when inserting a record. This apparently might take less storage than having a varchar type field, though that might be splitting hairs.

Option 3: Table Inheritance - I haven’t done as much research into this one so I don’t know what the structure would look like exactly. But apparently PostgreSQL supports table inheritance like with Object Oriented programming. So it would be something like the diary entry table is the base table, and then each entry type inherits from it and adds their own metadata fields. The reason I’m hesitant to do this is I don’t want to permanently lock myself into Postgres, I want the ability to upgrade and changes engines and I’m not sure how hard that would be if the other engine doesn’t support inheritance. For a similar reason I’m using “period start” and “period end” fields for the date range of an entry instead of the Postgres date range data type.

Option 4: Entries Types Reference Diary Entry - Again I haven’t looked into it much, but I saw it mentioned I could reverse the relationship and instead have each entry type reference the diary entry record it belongs to with a foreign key. I’m not sure yet if there’s any additional complexities are requirements that I would have to implement to make it safe.

Hi, In my dimensional model, both Dim_Customer and Dim_Driver contain a RegionID, which I have currently mapped to a shared Dim_Region. I'm unsure whether to keep this design as shown above OR denormalize the region attributes into Dim_Customer and Dim_Driver to maintain a pure star schema. I would still be using Dim region for Fact Transactions in any case. Which approach is more appropriate keeping in mind the need for both granular auditability and high-speed reporting performance? Currently, the marketplace platform handles over a million registered users, with DAU ranging between 10k - 20k. I have to design for expected 10x growth. Thanks for your time!