1.We can’t use queryMore() with custom metadata, but we can use the SOQL keywords LIMIT and OFFSET to page through large numbers of records. For more information
2.Custom metadata types support the following custom field types.
Checkbox
Date
Date and Time
Email
Number
Percent
Phone
Picklist
Text
Text Area
URL
3.Custom metadata types and records have names and labels. Type names must be unique within their namespace. Record names must be unique within their custom metadata type and namespace.
4.Use SOQL to access your custom metadata types and to retrieve the API names of the records on those types.
5.DML operations aren’t allowed on custom metadata in Apex, the Partner APIs, and Enterprise APIs.
6.The records of custom metadata types are metadata.So We can deply the records of Custom metadata type while in custom setting we can only insert record using Dataloader.
7.Records in protected (hidden) custom metadata types are developer editable only. That may sound obvious, but this is an important distinction from protected custom settings.
8.With custom metadata types, we can issue unlimited Salesforce Object Query Language (SOQL) queries for each Apex transaction.
Custom Metadta Type Limits:
Enterprises ease their compliance headaches
If your use of configuration objects is relatively limited (few objects and/or few records in those objects), and if you don’t create or update configurations often, building app configurations with custom settings or custom objects might be a reasonable strategy.
However, a typical enterprise using Force.com has tens or hundreds of custom objects or list custom settings acting as configuration objects. Every time a record is created or updated in a developer org, it then has to be moved to various other orgs. Often, it goes to integration testing, then user acceptance testing, then is deployed to production. And of course, it could go to multiple production orgs.
In every step of this process, developers or administrators must move those records. Some enterprises script the migration of their app configurations using a combination of the metadata and data APIs. While the API operations can be sequenced, they are disjoint and can’t be combined into a single deployment transaction, complicating the migration of application configurations. In addition, these scripts can be expensive to develop, test, and update.
As a result, many enterprises rely on manual processes, such as using data loader to move records or even opening two browser windows and copy/pasting records. And this isn’t a one-and-done process. It has to be done at each step of the software development lifecycle.
This process is expensive, error-prone, and most importantly, a huge headache for compliance. Manual processes are the archenemy of compliance.
Protected custom metadata types
Records in protected (hidden) custom metadata types are developer editable only. That may sound obvious, but this is an important distinction from protected custom settings.
Your code can edit and add records to protected custom settings, but it cannot do so in protected custom metadata types. This is because Apex can create, update and delete data but cannot do so natively for metadata. (You can help bump up the priority of adding this capability by voting for “Ability to update Metadata from Apex” in IdeaExchange.) The only way to create or update records in protected types is by upgrading your managed package.
This supports some important use cases. However, in some cases you may want your customer or your code to add or modify some records while others are hidden. The best way to achieve this now is by using two tables that do essentially the same thing, protect one of them and leave the other visible.
Metadata relationships
After we add these features, the next exciting enhancement on our roadmap is the ability to add relationships from your custom metadata to other things in your app, such as other custom metadata, custom or standard objects and fields, and static recourses.
Because custom settings do not support relationship fields, some developers use custom objects to store app configurations instead of (or in addition to) list custom settings. When metadata relationships are released, custom metadata types will be able to replace the custom objects your app uses as configuration objects.
Until then you will need to create metadata relationships the same way you create relationships for custom settings: by using an API name in a text field. Though not ideal, this is common practice for custom settings.
Difference in List Custom Setting and Custom Metadata Types:
