uhh… have you used Altium database libraries? It is (more or less) exactly like Altium does it…
I setup mine by following this guide (I lost the original forum post url).
It shows how to setup an example database lib with a few components. The steps are relatively simple. Basically:
- Install odbc driver.
- Download the example database.
- Create the odbc link to the database file.
- Setup paths in Kicad.
- Start drawing schematics with the components.
I build my db by adding more components, adding more fields, and importing other DBs (some are from Altium) to it later.
1 Like
No I have not, it was long ago I just shortly tested the software, which was a mess for me, then, I just thought the library parts in Altium nowadays was easy as their software is so widely used/so popular.
if people being non-programmers should even think about this
Its not a programmer thing. Its a do you use a database thing.
See many of you have it the wrong way around. This is not a replacement for normal libraries. Its a tie in to a database for those that already put stuff in a database because it convenient if you have a person that manages stuff for many people. Its not terribly good fit if you only work alone and have only a handful of projects.
If you don’t have a database for other things than you probably don’t need a database for libraries either.
When do you need a database? You need it when you need to store large amounts of data that may be needed by lots of people.
An example of a database need is this website. Every post goes into a database. and every thread is a fetch to a database, every edit goes into the database. This way there can be multiple things serving the page at the same time.
I am still trying to understand the use cases of the database feature. And I still can not imagine a workflow where it is useful. Do not understand me wrong I do not want sound negative, I just can not wrap my head around it even after watching the KiCon video and reading through this thread…
This comes to mind first. Centralized library for more people. But then it does not store footprints and symbols - it only references them by name? So still would need another way to store large amounts of data and to make things worse - some mechanism to keep them synchronized…
Using it for other big libraries like JLCPCB or Mouser catalogs? These databases contains a lot of information but not the relation to KiCad footprints and symbols… So it could not be used more than a search feature unless someone put in a lot of effort of adding and updating KiCad relations…
Using it as Jon presented - one layer abstraction over symbols and footprints. But this could be usefull even without a database, one simple text file could be enough. And also how usefull is the feature “update the symbol and footprint if the library changes…”. So yeah I can have a european resistors and “bulk replace” them with US ones… But for more complicated symbols it would be total pain in the behind and the designer still would need to check every symbol one by one…
Even though I am a single KiCad user and it is more a sidehustle for me, I do appreciate every way to organize and automate the process… That is why I do use Inventree, Kibot, Git etc even though it takes probably more time to deploy, debug and maintain that it saves but I think it is worth it. I am excited for the new Inventree binding even though I can not envision how it could replace my current workflow completely.
This is perfectly fine! Database libraries are a specialty feature that are only applicable to some users. They are not supposed to be applicable to everyone, and definitely are not supposed to replace the existing KiCad library workflow.
The typical way I see people doing this is with VCS (store library in a Git repository) or sometimes with a centrally-managed shared drive.
This is not really what database libraries is for in my opinion – it’s for data you control, not importing data from a third-party service. Although there is nothing keeping you from taking data you control and then adding to it from a third-party service.
A simple text file comes with lots of limitations and drawbacks, especially when you have more than one person interacting with it at the same time.
I think database libraries are almost never the right answer for single users (unless they really like databases) and agree that if InvenTree and HTTP libraries works better for you, it’s probably a better fit.
I do understand that and I am basically just curious for what users and how do they use it 
This sounds like a terrible combo to me. Having part of the data in VCS with version control and part in DB - all mine instincts scream “No!” in unison I am using git for libraries and it is a perfect way how to keep the libraries organized. Every project has them as submodules and keeps track of which commit of the submodule is being used. I can pull a newer version if I need but also I can just clone the year old version and it will still use the submodules it had a year ago. I can not imagine a way how to keep a database in sync with history of the VCS. That is also why I mentioned the simple text file as it could be in VCS and versioned by it.
The same applies to Inventree - I love it for managing my stock and additional info about parts I use (where to buy them, datasheets, notes, etc…) but I can not see it as “a library storage”. The best combo would be to have it point to git repo with the part.
You may be right - however there are some crazy users that may use them even though it seems counter intuitive. For example I am using KiBot automation with Git and as I said, maintaining it takes probably more time than it has saved. And friend of mine asked me: “Why is that better than just clicking here and here and here in KiCad?” The difference is that he comes from EE background while my background is in software. I prefer to automate every repetive task if possible…
That’s the thing. Database libraries are for professional work/organizations. Single users should never need them. Your normal use of libraries will suffice and in fact you can store all your custom data directly in symbol fields. That’s what I do, at home. A external text file to the libraries is just duplicating what the library files can already do for you.
At my work, we all our components in the ERP that runs the entire company and every department including HR which we can filter out to CAD tools.
My core background is in software and I do EE. Yet I click GUIs because I hate wasting time maintaining things 
In practice, it works really well. You don’t have to have perfect synchronization between the VCS and the database, because the VCS only contains the graphics. So for example if something is updated in the database to point to a new symbol, and another user hasn’t updated VCS yet so they don’t have that new symbol, it is not a serious issue – they just have to do an update and then the symbol can be found.
In general with this workflow you never want to use an “old” version of a library. So there is never a reason to check out an older version of the symbol/footprint VCS, and the database doesn’t really trivially allow access to “old versions” anyway. When an existing symbol or footprint has to be changed, old projects will use the cached version in the schematic/board file until/unless they are updated – there is no need to keep around an “old version library” for these projects that haven’t been updated yet.
Why not, let everyone pick their poison. I just prefer the machine in front of me to do the thing it is designed for - automating the repetitve tasks. It reminds me of one girl from accounting that used Excel in similair way. She entered like 200 numbers in the column, then took a calculator, summed them together and entered the sum into the Excel… 
But on a more serious note, I do not want to waste a PCB fabrication turnaround just to find out I forgot to click something somewhere…
This sounds a really dangerous to me. You say that the graphics is not that important to have it perfectly synchronized. With combination:
I can not imagine the situation that I clone out my project (PCB or SW project) and that the output depends on when I do clone it… I’ve just been reviewing some of my program from 2013 because of a strange bug… I can not imagine not having exactly the same source code as in 2013… And yeah, it is “solved” by the caching in the project but I see that more as a workaround than a “feature to realy on…”.
For example now I am adding a HDMI connector to my board that uses Rapsberry PI CM4. I have done the same on different board two years ago. So I did clone out that repo exactly as it has been 2 years ago and I am looking if I can use the same connector or if I need to replace it with a connector that I can have assembled today. The previous board was assembled by PCBWAY and they sourced all the parts but now I will use JLCPCB and I need to choose a connector from their library. So it would be nice to have a “HDMI connector” part somewhere and just use that. However the same connector is not available in JLC and I need to compare the footprint (just the graphics) if I need to redo it or can use the existing one. On the other hand I may need to order some of the old boards from PCBWAY so I would like to use the old design for that - but some parts will not be available and I will need to change it. But just the parts that I need to change as I do want to change only the necessary minimum. I can not imagine cloning out the design from Git and having all footprints replaced by the new versions… (I know that the caching feature would prevent that but the DRC and ERC would go really creazy about Footprint/Symbol not matiching library…)
This doesn’t happen though, because KiCad projects are standalone and don’t depend on the state of libraries.
My workflow would require that you create two different HDMI connector parts (possibly sharing one symbol, if they are pin-compatible).
This is why you would never just update your “HDMI connector” footprint in order to deal with switching to a different HDMI connector: you would create a new line item for a different specific HDMI connector, and it would contain a different manufacturer part number, maybe same symbol, and maybe different footprint. You would not get library mismatch ERC/DRC, because you didn’t change the old one.
The reason to change the old one is if you find that you made the footprint incorrectly, for example. In this case you do want the DRC/ERC to point out a library mismatch, so you know you have to update the design to get rid of the incorrect footprint.
Well, that is a matter of opinion. I consider the project in whole even with the libraries - as for example the 3D models does not get cached in the project. As I mentioned I do consider the caching in project feature more than “an emergency stop” than “normal brake” thing. But I understand your point I just feel a little different about the small nuances
I understand that and that is what I am doing also. But what I meant is more that the part library would have a “approved and vetted HDMI connector” part so if I just need a HDMI connector and do not care much about which one, I just use this one part and be done with it…
But I do understand what you are saying, as I said, I am just curious how others do things so I can maybe incorporate something from that into my workflows…
I remember it being worse. Something 32/64 bit conflict with office installation. Got it working though.
See here Creating & Defining the Database Library in Altium Designer | Altium Designer 23 Technical Documentation
What is definitely better at Altium is the parts filter panel. That will need some work at KiCad before it gets usable.
Database work is really the same as with KiCad, as far as I can tell.
@TheSwede : Your point that database libraries are usable for programmers only is valid. However the only way you could profit from databases without messing yourself with their innards is using database libraries someone else has build. I could imagine that Würth (they announced full KiCad support) or JLC (wishful thinking) would provide libraries (maybe installable via plugin manager) you could use.
One thing that make both Altium and KiCad database libraries extra messy is the open database interface (or the lack of a builtin database). This is neat for interfacing with a company database server, but you can’t just quickly add a SQLite database.
Maybe if using prebuilt libraries (like JLCPCB assembly library) in a single-user read-only fashion, a builtin SQLite engine would be nice as it could bypass all the ODBC connection string hassle.
But this is the whole point of the current database libraries feature: interfacing with a (company, or non-company) database server.
If you want some kind of new KiCad library that is built-in to KiCad, that would be a separate feature.
There is not currently any open feature request that I can find that is asking for some different kind of built-in library, but someone could make one if they can describe what they want…
Primarily (and for now), yes.
However suppose Würth Elektronik provides a library for all their chip ferrites. Instead making classic libraries (where the inductor symbol is duplicated 1000x), they could make schematic and footprint libraries and link them with one database library.
Currently they could provide a SQLite database library, but would have to instruct users where to get a SQLite engine and how to configure for example ODBC on Windows for that, which would be rather user-unfriendly assuming a target audience expecting a one-click library install.
For this case a builtin SQLite database engine (where you would only have to provide the database file) would make sense.
I think this is a use case that is not that relevant in more professional systems, as noone would send an unverified part from a random internet source into mass production, there would always be a librarian/component engineer involved, so easy access to existing libraries is not really relevant.
For KiCad however, users are more DIY, education or R&D rapid prototyping, where quick access to many components is a big help.
We don’t encourage manufacturers to do this. Standard format libraries are more applicable than database libraries for them.
From official Kicad documentation:
| | | Documentation | KiCad
“KiCad does not provide a GUI for editing a SQL database or defining a database library. It is up to the user to find the most appropriate workflow and toolchain for creating and updating the database itself. Some users may want to directly edit the database through a third-party database client, and some may use other third-party software such as a part lifecycle management (PLM) tool to create and edit data.”
Just want to say: every interest parties will have their own goal with their database. E.g. for some people, it can tie to a bigger ERP database. For Wurth, they want customer easier access and exposure to their product. For other, may be just want a easier way to collaborate and minimize human error. Etc. And therefore, different workflows, different database formats exist.
OK then, different example. Jan has this nice database interface to JLCPCB assembly parts:
https://yaqwsx.github.io/jlcparts/#/
I’d like to have a part selector panel in KiCad where I can for example place a chip resistor or capacitor from their library and have all data in KiCad (primarily the LCSC order number). At least for simple components like chip capacitors or resistors there are very few standard symbols and footprints and it would be a natural match to pack all those in a database library. I have this working for Altium and also a small demo with KiCad.
Ideally on this page you could download a database library (updated periodically) with all discretes available for JLCPCB assembly.
Of course one could argue that you can expand any read-only database into the regular library, but I’d consider this as unnecessarily messy and unelegant, particularly now that the database interface is available.
am still trying to understand the use cases of the database feature
Yes and i can understand that. If you don’t have a need for a database you have no need for a database.
It very unlikely that a organization or individual person would switch to using a database because of kicad directly. What would happen is that they are using a database for another reason to begin with. They might have a database for their inventory, client orders, quality control, support tickets, internal documentation, product lifecycle management, etc.
In any event the database may at some have overlapping functions with your kicad designs. The reasons could be numerous, maybe your orders go trough the database, your BOM goes to the database or something to that effect. Now the use case for the database is much more easier to understand.
At simplest the move to database offers ease of management. Since everything is already in a database at simplest having it in a database helps you as you don’t need to duplicate data between kicad and whatever else your doing with the database, since it already there.
Lets demonstrate this with a naive example, lets say that you are hosting your own datasheets, perhaps to enable other to put comments in the datasheet documents or something. Now imagine your switching servers then its just on command for whoever needs to manage of your document server to update all the links. Now you probably don’t want to do this in reality just trying to come up with understandable scenarios. In reality you’d use this for something like not for new products notifications or something.
Alternative things is your boss wants your purchasing department to manage the components that get finally put on the device. By having your own database (not a vendor database!), you can tie your passives to multiple vendors depending on what is cheapest or by availability. So this means your not choosing a component directly but instead some internal standard instead and the database facilitates the task of purchasing department or maybe quality control department.